Messages in this thread | | | Date | Tue, 15 Sep 2009 21:26:01 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: [PATCH 5/8] mm: follow_hugetlb_page flags |
| |
On Mon, 14 Sep 2009, Mel Gorman wrote: > On Sun, Sep 13, 2009 at 04:35:44PM +0100, Hugh Dickins wrote: > > On Wed, 9 Sep 2009, Mel Gorman wrote: > > > > and called something like hugetlbfs_pagecache_present() > > > > Can call it that if you prefer, either name suits me. > > I don't feel strongly enough to ask for a new version. If this is not > the final version that is merged, then a name-change would be nice. > Otherwise, it's not worth the hassle.
You've raised several points, so worth a patch on top to keep you sweet!
> > > or else reuse > > > the function and have the caller unlock_page but it's probably not worth > > > addressing. > > > > I did originally want to do it that way, but the caller is holding > > page_table_lock, so cannot lock_page there. > > Gack, fair point. If there is another version, a comment to that effect > wouldn't hurt.
Righto, done.
> And nothing else other than core dumping will be using FOLL_DUMP so > there should be no assumptions broken.
You have no idea of the depths of depravity to which I might sink: see patch 1/4 in the coming group, you might be inclined to protest.
> > But it does seem that we've confused each other: what to say instead? > > /* > * When core-dumping, it's suits the get_dump_page() if an error is > * returned if there is a hole and no huge pagecache to back it. > * get_dump_page() is concerned with individual pages and by > * returning the page as an error, the core dump file still gets > * zeros but a hugepage allocation is avoided. > */
I've added a sentence to that comment, not quite what you've suggested above, but something I hope makes it clearer.
Hugh
| |