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 map
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 y
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 t
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/dm
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 page_buffers(page)
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, 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 s
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
> reclaimab
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 unsubscrib
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 t
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, 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 i
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 mm
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 w
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 go
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 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 mm
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 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 _
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 whic
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 map
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 ap
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 p
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 t
31 matches
Mail list logo
