On Tue, 24 Apr 2007, Andrew Morton wrote:
> mapping_gfp_mask if a pretty foul thing. Adding
>
> struct page (*alloc_page)(struct address_space *mapping);
>
> to address_space_operations would be a quite nice cleanup.
Ummm... If things would be that simple... I think we need
struct page
On Tue, 24 Apr 2007 13:58:35 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Tue, 24 Apr 2007, Andrew Morton wrote:
>
> > > Then I think we should disable page migration for allocations that do not
> > > allow access to the policy zone. That would fix it.
> >
> > Can't we use
On Tue, 24 Apr 2007, Andrew Morton wrote:
> > Then I think we should disable page migration for allocations that do not
> > allow access to the policy zone. That would fix it.
>
> Can't we use mapping_gfp_mask() when allocating the destination page?
There is no point in migrating something if
On Tue, 24 Apr 2007 13:44:50 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Tue, 24 Apr 2007, Andrew Morton wrote:
>
> > > I would say that the filesystem is broke if it has such expectations
> > > regardless of page migration.
> >
> > Others disagree ;)
> >
> > The filesystem
On Tue, 24 Apr 2007, Andrew Morton wrote:
> > I would say that the filesystem is broke if it has such expectations
> > regardless of page migration.
>
> Others disagree ;)
>
> The filesystem has *told* the core kernel what its allocation constraints
> are by setting up mapping_gfp_mask(). If
On Tue, 24 Apr 2007 13:30:33 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> > > If the system has both high memory and normal memory then only
> > > allocations
> > > to highmemory are subject to memory policies etc etc. The block device
> > > allocations would be in zone
On Tue, 24 Apr 2007, Hugh Dickins wrote:
> On Tue, 24 Apr 2007, Christoph Lameter wrote:
> > On Tue, 24 Apr 2007, Hugh Dickins wrote:
> >
> > > Or Christoph may prevail in persuading there's no such problem.
> >
> > This is pointless. NUMA allocations can only be controlled for the highest
> >
On Tue, 24 Apr 2007 13:12:42 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Tue, 24 Apr 2007, Andrew Morton wrote:
>
> > > A highmem page can have buffers???
> >
> > yep. Take a 4k page which is stored in four discontiguous 1k disk blocks.
> > The
> > data at
On Tue, 24 Apr 2007, Christoph Lameter wrote:
> On Tue, 24 Apr 2007, Hugh Dickins wrote:
>
> > Or Christoph may prevail in persuading there's no such problem.
>
> This is pointless. NUMA allocations can only be controlled for the highest
> zone. If we switch to a lower zone then we allocate on
On Tue, 24 Apr 2007, Andrew Morton wrote:
> > A highmem page can have buffers???
>
> yep. Take a 4k page which is stored in four discontiguous 1k disk blocks. The
> data at page_buffers(page) is the sole way in which we track which parts of
> the page belong to which blocks of the disk.
But I
On Tue, 24 Apr 2007 12:59:17 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Tue, 24 Apr 2007, Andrew Morton wrote:
>
> > No, think of the following scenario:
> >
> > - file I/O causes a read of an ext2 file's bitmap. The bitmap is
> > brought into /dev/hda1's pagecache using
On Tue, 24 Apr 2007, Andrew Morton wrote:
> No, think of the following scenario:
>
> - file I/O causes a read of an ext2 file's bitmap. The bitmap is
> brought into /dev/hda1's pagecache using !__GFP_HIGHMEM
>
> - references are released against that page and it's now just clean
>
On Tue, 24 Apr 2007, Hugh Dickins wrote:
> Or Christoph may prevail in persuading there's no such problem.
This is pointless. NUMA allocations can only be controlled for the highest
zone. If we switch to a lower zone then we allocate on a different zone
than the user requested.
-
To
On Tue, 24 Apr 2007 12:34:53 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> > Not as metadata, no. But someone (let's hope only root, though I may
> > be wrong on that) can map any part of the block device into userspace.
>
> Concurrent access to a block device by a filesystem and
On Tue, 24 Apr 2007, Hugh Dickins wrote:
> I was certainly ignorant of that; but I'm not convinced it eliminates
> the potential issue. For a start, sys_move_pages seems not to involve
> mempolicies at all - I don't see what prevents it migrating blockdev
> pages away from the only node which
On Tue, 24 Apr 2007, Andrew Morton wrote:
>
> From my reading it would be pretty simple to teach unmap_and_move()
> to pass mapping_gfp_mask(page_mapping(page)) down into
> (*get_new_page)() to get the correct type of page.
Or even simpler, since they're already passed the source page,
just get
On Tue, 24 Apr 2007, Christoph Lameter wrote:
> On Tue, 24 Apr 2007, Hugh Dickins wrote:
>
> > I've not yet looked at the patch under discussion, but this remark
> > prompts me... a couple of days ago I got very worried by the various
> > hard-wired GFP_HIGHUSER allocations in mm/migrate.c and
On Tue, 24 Apr 2007, Andrew Morton wrote:
> > I think that much is also true, but not where the problem lies.
> > Isn't the problem that filesystems using these block devices
> > expect their metadata to be accessible without kmap calls?
> >
>
> yup. wherever we dereference buffer_head.b_data
On Tue, 24 Apr 2007 18:45:03 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]> wrote:
> On Tue, 24 Apr 2007, Christoph Lameter wrote:
> > On Tue, 24 Apr 2007, Hugh Dickins wrote:
> >
> > > I've not yet looked at the patch under discussion, but this remark
> > > prompts me... a couple of days ago I
On Tue, 24 Apr 2007, Hugh Dickins wrote:
> > And if a page is in the wrong area then it can be bounced before I/O
> > is performed on it.
>
> I think that much is also true, but not where the problem lies.
> Isn't the problem that filesystems using these block devices
> expect their metadata to
On Tue, 24 Apr 2007, Hugh Dickins wrote:
> I've not yet looked at the patch under discussion, but this remark
> prompts me... a couple of days ago I got very worried by the various
> hard-wired GFP_HIGHUSER allocations in mm/migrate.c and mm/mempolicy.c,
> and wondered how those would work out
On Tue, 24 Apr 2007, Christoph Lameter wrote:
> On Tue, 24 Apr 2007, Hugh Dickins wrote:
>
> > I've not yet looked at the patch under discussion, but this remark
> > prompts me... a couple of days ago I got very worried by the various
> > hard-wired GFP_HIGHUSER allocations in mm/migrate.c and
On Tue, 24 Apr 2007, Hugh Dickins wrote:
> I've not yet looked at the patch under discussion, but this remark
> prompts me... a couple of days ago I got very worried by the various
> hard-wired GFP_HIGHUSER allocations in mm/migrate.c and mm/mempolicy.c,
> and wondered how those would work out
On Tue, 24 Apr 2007 14:09:33 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]> wrote:
> On Mon, 23 Apr 2007, Andrew Morton wrote:
> >
> > OK. I hope. the mapping_gfp_mask() here will have come from bdget()'s
> > mapping_set_gfp_mask(>i_data, GFP_USER); If anyone is accidentally
> > setting
On Mon, 23 Apr 2007, Andrew Morton wrote:
>
> OK. I hope. the mapping_gfp_mask() here will have come from bdget()'s
> mapping_set_gfp_mask(>i_data, GFP_USER); If anyone is accidentally
> setting __GFP_HIGHMEM on a blockdev address_space we'll cause ghastly
> explosions. Albeit ones which were
On Mon, 23 Apr 2007, Andrew Morton wrote:
OK. I hope. the mapping_gfp_mask() here will have come from bdget()'s
mapping_set_gfp_mask(inode-i_data, GFP_USER); If anyone is accidentally
setting __GFP_HIGHMEM on a blockdev address_space we'll cause ghastly
explosions. Albeit ones which were
On Tue, 24 Apr 2007 14:09:33 +0100 (BST) Hugh Dickins [EMAIL PROTECTED] wrote:
On Mon, 23 Apr 2007, Andrew Morton wrote:
OK. I hope. the mapping_gfp_mask() here will have come from bdget()'s
mapping_set_gfp_mask(inode-i_data, GFP_USER); If anyone is accidentally
setting __GFP_HIGHMEM
On Tue, 24 Apr 2007, Hugh Dickins wrote:
I've not yet looked at the patch under discussion, but this remark
prompts me... a couple of days ago I got very worried by the various
hard-wired GFP_HIGHUSER allocations in mm/migrate.c and mm/mempolicy.c,
and wondered how those would work out if
On Tue, 24 Apr 2007, Hugh Dickins wrote:
I've not yet looked at the patch under discussion, but this remark
prompts me... a couple of days ago I got very worried by the various
hard-wired GFP_HIGHUSER allocations in mm/migrate.c and mm/mempolicy.c,
and wondered how those would work out if
On Tue, 24 Apr 2007, Christoph Lameter wrote:
On Tue, 24 Apr 2007, Hugh Dickins wrote:
I've not yet looked at the patch under discussion, but this remark
prompts me... a couple of days ago I got very worried by the various
hard-wired GFP_HIGHUSER allocations in mm/migrate.c and
On Tue, 24 Apr 2007, Hugh Dickins wrote:
And if a page is in the wrong area then it can be bounced before I/O
is performed on it.
I think that much is also true, but not where the problem lies.
Isn't the problem that filesystems using these block devices
expect their metadata to be
On Tue, 24 Apr 2007 18:45:03 +0100 (BST) Hugh Dickins [EMAIL PROTECTED] wrote:
On Tue, 24 Apr 2007, Christoph Lameter wrote:
On Tue, 24 Apr 2007, Hugh Dickins wrote:
I've not yet looked at the patch under discussion, but this remark
prompts me... a couple of days ago I got very
On Tue, 24 Apr 2007, Andrew Morton wrote:
I think that much is also true, but not where the problem lies.
Isn't the problem that filesystems using these block devices
expect their metadata to be accessible without kmap calls?
yup. wherever we dereference buffer_head.b_data we're
On Tue, 24 Apr 2007, Christoph Lameter wrote:
On Tue, 24 Apr 2007, Hugh Dickins wrote:
I've not yet looked at the patch under discussion, but this remark
prompts me... a couple of days ago I got very worried by the various
hard-wired GFP_HIGHUSER allocations in mm/migrate.c and
On Tue, 24 Apr 2007, Andrew Morton wrote:
From my reading it would be pretty simple to teach unmap_and_move()
to pass mapping_gfp_mask(page_mapping(page)) down into
(*get_new_page)() to get the correct type of page.
Or even simpler, since they're already passed the source page,
just get it
On Tue, 24 Apr 2007, Hugh Dickins wrote:
I was certainly ignorant of that; but I'm not convinced it eliminates
the potential issue. For a start, sys_move_pages seems not to involve
mempolicies at all - I don't see what prevents it migrating blockdev
pages away from the only node which has
On Tue, 24 Apr 2007 12:34:53 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
Not as metadata, no. But someone (let's hope only root, though I may
be wrong on that) can map any part of the block device into userspace.
Concurrent access to a block device by a filesystem and the
On Tue, 24 Apr 2007, Hugh Dickins wrote:
Or Christoph may prevail in persuading there's no such problem.
This is pointless. NUMA allocations can only be controlled for the highest
zone. If we switch to a lower zone then we allocate on a different zone
than the user requested.
-
To
On Tue, 24 Apr 2007, Andrew Morton wrote:
No, think of the following scenario:
- file I/O causes a read of an ext2 file's bitmap. The bitmap is
brought into /dev/hda1's pagecache using !__GFP_HIGHMEM
- references are released against that page and it's now just clean
reclaimable
On Tue, 24 Apr 2007 12:59:17 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
On Tue, 24 Apr 2007, Andrew Morton wrote:
No, think of the following scenario:
- file I/O causes a read of an ext2 file's bitmap. The bitmap is
brought into /dev/hda1's pagecache using
On Tue, 24 Apr 2007, Andrew Morton wrote:
A highmem page can have buffers???
yep. Take a 4k page which is stored in four discontiguous 1k disk blocks. The
data at page_buffers(page) is the sole way in which we track which parts of
the page belong to which blocks of the disk.
But I see no
On Tue, 24 Apr 2007, Christoph Lameter wrote:
On Tue, 24 Apr 2007, Hugh Dickins wrote:
Or Christoph may prevail in persuading there's no such problem.
This is pointless. NUMA allocations can only be controlled for the highest
zone. If we switch to a lower zone then we allocate on a
On Tue, 24 Apr 2007 13:12:42 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
On Tue, 24 Apr 2007, Andrew Morton wrote:
A highmem page can have buffers???
yep. Take a 4k page which is stored in four discontiguous 1k disk blocks.
The
data at page_buffers(page) is the sole
On Tue, 24 Apr 2007, Hugh Dickins wrote:
On Tue, 24 Apr 2007, Christoph Lameter wrote:
On Tue, 24 Apr 2007, Hugh Dickins wrote:
Or Christoph may prevail in persuading there's no such problem.
This is pointless. NUMA allocations can only be controlled for the highest
zone. If we
On Tue, 24 Apr 2007 13:30:33 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
If the system has both high memory and normal memory then only
allocations
to highmemory are subject to memory policies etc etc. The block device
allocations would be in zone normal/dma and thus be
On Tue, 24 Apr 2007, Andrew Morton wrote:
I would say that the filesystem is broke if it has such expectations
regardless of page migration.
Others disagree ;)
The filesystem has *told* the core kernel what its allocation constraints
are by setting up mapping_gfp_mask(). If the core
On Tue, 24 Apr 2007 13:44:50 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
On Tue, 24 Apr 2007, Andrew Morton wrote:
I would say that the filesystem is broke if it has such expectations
regardless of page migration.
Others disagree ;)
The filesystem has *told* the
On Tue, 24 Apr 2007, Andrew Morton wrote:
Then I think we should disable page migration for allocations that do not
allow access to the policy zone. That would fix it.
Can't we use mapping_gfp_mask() when allocating the destination page?
There is no point in migrating something if you
On Tue, 24 Apr 2007 13:58:35 -0700 (PDT) Christoph Lameter [EMAIL PROTECTED]
wrote:
On Tue, 24 Apr 2007, Andrew Morton wrote:
Then I think we should disable page migration for allocations that do not
allow access to the policy zone. That would fix it.
Can't we use
On Tue, 24 Apr 2007, Andrew Morton wrote:
mapping_gfp_mask if a pretty foul thing. Adding
struct page (*alloc_page)(struct address_space *mapping);
to address_space_operations would be a quite nice cleanup.
Ummm... If things would be that simple... I think we need
struct page
On Mon, 23 Apr 2007 15:33:07 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Grow dev page simply passes GFP_NOFS to find_or_create_page. This means the
> allocation of radix tree nodes is done with GFP_NOFS and the allocation
> of a new page is done using GFP_NOFS as well.
>
> The
And the second fix (cleanup patch will follow)
Pagecache: find_or_create_page does not spread memory.
The find_or_create function calls alloc_page with the gfp_mask passed to it
which is derived from the mappings gfp mask. So the allocation flags are right
(assuming my bugfix to fs/buffer.c is
On Mon, 23 Apr 2007, Andrew Morton wrote:
> There are few calls to page_cache_alloc(). Would it not be simpler to just
> add the additional argument to page_cache_alloc() (called "extra_gfp",
> please) and to update all callers? And to remove page_cache_alloc_cold()
> and replace all it callers
On Mon, 23 Apr 2007, Andrew Morton wrote:
> > +static inline struct page *page_cache_alloc_mask(struct address_space *x,
> > + gfp_t gfp)
> > +{
> > + return __page_cache_alloc(mapping_gfp_mask(x) | gfp);
> > +}
>
> Usually we use the term "mask" to imply an AND function, not
On Mon, 23 Apr 2007 14:11:57 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> The find_or_create function calls alloc_page with a local gfp mask instead
> of using page_cache_alloc. This means that the page allocation will not
> obey cpuset memory spreading and page allocation will not
The find_or_create function calls alloc_page with a local gfp mask instead
of using page_cache_alloc. This means that the page allocation will not
obey cpuset memory spreading and page allocation will not properly use the
gfp flags in the address space. Highmem is not set correctly.
It turns out
The find_or_create function calls alloc_page with a local gfp mask instead
of using page_cache_alloc. This means that the page allocation will not
obey cpuset memory spreading and page allocation will not properly use the
gfp flags in the address space. Highmem is not set correctly.
It turns out
On Mon, 23 Apr 2007 14:11:57 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
The find_or_create function calls alloc_page with a local gfp mask instead
of using page_cache_alloc. This means that the page allocation will not
obey cpuset memory spreading and page allocation will not
On Mon, 23 Apr 2007, Andrew Morton wrote:
+static inline struct page *page_cache_alloc_mask(struct address_space *x,
+ gfp_t gfp)
+{
+ return __page_cache_alloc(mapping_gfp_mask(x) | gfp);
+}
Usually we use the term mask to imply an AND function, not an OR
On Mon, 23 Apr 2007, Andrew Morton wrote:
There are few calls to page_cache_alloc(). Would it not be simpler to just
add the additional argument to page_cache_alloc() (called extra_gfp,
please) and to update all callers? And to remove page_cache_alloc_cold()
and replace all it callers with
And the second fix (cleanup patch will follow)
Pagecache: find_or_create_page does not spread memory.
The find_or_create function calls alloc_page with the gfp_mask passed to it
which is derived from the mappings gfp mask. So the allocation flags are right
(assuming my bugfix to fs/buffer.c is
On Mon, 23 Apr 2007 15:33:07 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
Grow dev page simply passes GFP_NOFS to find_or_create_page. This means the
allocation of radix tree nodes is done with GFP_NOFS and the allocation
of a new page is done using GFP_NOFS as well.
The mapping
62 matches
Mail list logo
