headers
Ed Tomlinson | 1 Feb 2003 02:18

Re: 2.5.59-mm7

Looks like something got missed...  I get this with mm7

if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.5.59-mm7; fi
WARNING: /lib/modules/2.5.59-mm7/kernel/arch/i386/kernel/apm.ko needs unknown symbol xtime_lock

Ed Tomlinson

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/
Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Feb 2003 02:45

Re: 2.5.59-mm7

Ed Tomlinson <tomlins <at> cam.org> wrote:
>
> Looks like something got missed...  I get this with mm7
> 
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map  2.5.59-mm7; fi
> WARNING: /lib/modules/2.5.59-mm7/kernel/arch/i386/kernel/apm.ko needs unknown symbol xtime_lock
> 

aww, that's not fair.

xtime_lock was _always_ referenced by apm.c, and never exported to modules.

The only reason it ever worked was that apm does not compile for SMP, and
write/read_lock() are no-ops on uniprocessor.

ho hum, thanks, I shall add the export.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/
Permalink | Reply | 0 comments |
headers
David Chow | 1 Feb 2003 10:18

Re: dirty pages path in kernel

> Andrew Morton writes:

>  > Andrew Morton wrote:

>  > >

>  > > David Chow <davidchow <at> shaolinmicro.com> wrote:

>  > > >

>  > > > Hi,

>  > > >

>  > > > If I do the following to an inode mapping page .

>  > > >

>  > > > 1. Generate a "struct page" from read_cache_page()

>  > > > 2. kmap() the page, do some memset() (Dirty the page)

>  > > > 3. kunmap() and page_cache_release() the page.

>  > > >

>  > >

>  > > The VFS does not know that the page has changed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ingo Oeser | 1 Feb 2003 09:58
Picon

Re: hugepage patches

Hi Andrew,

On Fri, Jan 31, 2003 at 03:18:58PM -0800, Andrew Morton wrote:
> Also, don't mark hugepages as all PageReserved any more.  That's preenting
> callers from doing proper refcounting.  Any code which does a user pagetable
> walk and hits part of a hugepage will now handle it transparently.

Heh, that's helping me a lot and makes get_one_user_page very
simple again (and simplify the follow_huge_* stuff even more).

This could help futex slow-path and remove loads of code.

Once this hugetlb stuff settles down a bit, I'll rewrite the
page-walking again to accomodate this. No API changes, just
internal rewrites.

So please tell the linux-mm list, when it's finished and I'll have
sth. ready for -mm in the first week of March[1].

Regards

Ingo Oeser

[1] Important exams in February, sorry.
--

-- 
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andrew Morton | 1 Feb 2003 10:31

Re: hugepage patches

Ingo Oeser <ingo.oeser <at> informatik.tu-chemnitz.de> wrote:
>
> Hi Andrew,
> 
> On Fri, Jan 31, 2003 at 03:18:58PM -0800, Andrew Morton wrote:
> > Also, don't mark hugepages as all PageReserved any more.  That's preenting
> > callers from doing proper refcounting.  Any code which does a user pagetable
> > walk and hits part of a hugepage will now handle it transparently.
> 
> Heh, that's helping me a lot and makes get_one_user_page very
> simple again (and simplify the follow_huge_* stuff even more).
> 
> This could help futex slow-path and remove loads of code.
> 
> Once this hugetlb stuff settles down a bit, I'll rewrite the
> page-walking again to accomodate this. No API changes, just
> internal rewrites.

OK...

> So please tell the linux-mm list, when it's finished and I'll have
> sth. ready for -mm in the first week of March[1].

Well I'm thinking of renaming it to hugebugfs.  It should be settled down
shortly.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/
(Continue reading)

Permalink | Reply | 2 comments |
headers
William Lee Irwin III | 1 Feb 2003 11:00

Re: hugepage patches

On Sat, Feb 01, 2003 at 01:31:36AM -0800, Andrew Morton wrote:
> Well I'm thinking of renaming it to hugebugfs.  It should be settled down
> shortly.

We've had a difference of opinion wrt. the proper mechanism for
referring things to the head of their superpage. I guess in one
sense I could be blamed for not following directions, but I _really_
didn't want to go in the direction of killing ->lru for all time.

There is also other shite I'd _really_ rather not get into publicly.

-- wli
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/
Permalink | Reply | 1 comment |
headers
Andrew Morton | 1 Feb 2003 11:14

Re: hugepage patches

William Lee Irwin III <wli <at> holomorphy.com> wrote:
>
> On Sat, Feb 01, 2003 at 01:31:36AM -0800, Andrew Morton wrote:
> > Well I'm thinking of renaming it to hugebugfs.  It should be settled down
> > shortly.
> 
> We've had a difference of opinion wrt. the proper mechanism for
> referring things to the head of their superpage. I guess in one
> sense I could be blamed for not following directions, but I _really_
> didn't want to go in the direction of killing ->lru for all time.

It's not killed - tons of stuff can be stuck at page[1].

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/
Permalink | Reply | 0 comments |
headers
Andrew Morton | 2 Feb 2003 11:55

Re: hugepage patches

5/4

get_unmapped_area for hugetlbfs

Having to specify the mapping address is a pain.  Give hugetlbfs files a
file_operations.get_unmapped_area().

The implementation is in hugetlbfs rather than in arch code because it's
probably common to several architectures.  If the architecture has special
needs it can define HAVE_ARCH_HUGETLB_UNMAPPED_AREA and go it alone.  Just
like HAVE_ARCH_UNMAPPED_AREA.

Having to specify the mapping address is a pain.  Give hugetlbfs files a
file_operations.get_unmapped_area().

The implementation is in hugetlbfs rather than in arch code because it's
probably common to several architectures.  If the architecture has special
needs it can define HAVE_ARCH_HUGETLB_UNMAPPED_AREA and go it alone.  Just
like HAVE_ARCH_UNMAPPED_AREA.

 hugetlbfs/inode.c |   46 ++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 44 insertions(+), 2 deletions(-)

diff -puN fs/hugetlbfs/inode.c~hugetlbfs-get_unmapped_area fs/hugetlbfs/inode.c
--- 25/fs/hugetlbfs/inode.c~hugetlbfs-get_unmapped_area	2003-02-01 01:13:03.000000000 -0800
+++ 25-akpm/fs/hugetlbfs/inode.c	2003-02-02 01:17:01.000000000 -0800
 <at>  <at>  -74,6 +74,47  <at>  <at>  static int hugetlbfs_file_mmap(struct fi
 }

 /*
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 2 Feb 2003 11:55

Re: hugepage patches

6/4

hugetlbfs: fix truncate

- Opening a hugetlbfs file O_TRUNC calls the generic vmtruncate() functions
  and nukes the kernel.

  Give S_ISREG hugetlbfs files a inode_operations, and hence a setattr
  which know how to handle these files.

- Don't permit the user to truncate hugetlbfs files to sizes which are not
  a multiple of HPAGE_SIZE.

- We don't support expanding in ftruncate(), so remove that code.

 hugetlbfs/inode.c |   39 ++++++++++++++++-----------------------
 1 files changed, 16 insertions(+), 23 deletions(-)

diff -puN fs/hugetlbfs/inode.c~hugetlbfs-truncate-fix fs/hugetlbfs/inode.c
--- 25/fs/hugetlbfs/inode.c~hugetlbfs-truncate-fix	2003-02-02 01:17:04.000000000 -0800
+++ 25-akpm/fs/hugetlbfs/inode.c	2003-02-02 01:17:04.000000000 -0800
 <at>  <at>  -34,6 +34,7  <at>  <at>  static struct super_operations hugetlbfs
 static struct address_space_operations hugetlbfs_aops;
 struct file_operations hugetlbfs_file_operations;
 static struct inode_operations hugetlbfs_dir_inode_operations;
+static struct inode_operations hugetlbfs_inode_operations;

 static struct backing_dev_info hugetlbfs_backing_dev_info = {
 	.ra_pages	= 0,	/* No readahead */
 <at>  <at>  -326,44 +327,29  <at>  <at>  static void hugetlb_vmtruncate_list(stru
(Continue reading)

Permalink | Reply | 15 comments |
headers
Andrew Morton | 2 Feb 2003 11:55

Re: hugepage patches

7/4

hugetlbfs i_size fixes

We're expanding hugetlbfs i_size in the wrong place.  If someone attempts to
mmap more pages than are available, i_size is updated to reflect the
attempted mapping size.

So set i_size only when pages are successfully added to the mapping.

i_size handling at truncate time is still a bit wrong - if the mapping has
pages at (say) page offset 100-200 and the mappng is truncated to (say_ page
offset 50, i_size should be set to zero.  But it is instead set to
50*HPAGE_SIZE.  That's harmless.

 i386/mm/hugetlbpage.c    |    5 +++++
 ia64/mm/hugetlbpage.c    |    0 
 sparc64/mm/hugetlbpage.c |    0 
 x86_64/mm/hugetlbpage.c  |    6 ++++++
 hugetlbfs/inode.c        |    5 -----
 5 files changed, 11 insertions(+), 5 deletions(-)

diff -puN fs/hugetlbfs/inode.c~hugetlbfs-i_size-fix fs/hugetlbfs/inode.c
--- 25/fs/hugetlbfs/inode.c~hugetlbfs-i_size-fix	2003-02-01 02:07:22.000000000 -0800
+++ 25-akpm/fs/hugetlbfs/inode.c	2003-02-01 02:07:22.000000000 -0800
 <at>  <at>  -45,7 +45,6  <at>  <at>  static int hugetlbfs_file_mmap(struct fi
 {
 	struct inode *inode =file->f_dentry->d_inode;
 	struct address_space *mapping = inode->i_mapping;
-	size_t len;
(Continue reading)

Permalink | Reply | 0 comments |

Gmane