Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Andrew Morton
Date: Friday, June 6, 2008 - 6:07 pm

On Fri, 06 Jun 2008 16:28:55 -0400
Rik van Riel <riel@redhat.com> wrote:


Oh sob.

akpm:/usr/src/25> find . -name '*.[ch]' | xargs grep CONFIG_NORECLAIM | wc -l
51

why oh why?  Must we really really do this to ourselves?  Cheerfully
unchangeloggedly?


How many page flags are left?  I keep on asking this and I end up
either a) not being told or b) forgetting.  I thought that we had
a whopping big comment somewhere which describes how all these
flags are allocated but I can't immediately locate it.


None of which is available on 32-bit machines.  That's pretty significant.


Do we do per-zone or global number-of-mlocked-pages accounting for
/proc/meminfo or /proc/vmstat, etc?  Seems not..


The sentence "when no swap space exists." a) lacks capitalisation and
b) makes no sense.

The paramedics are caring for Aunt Tillie.


I don't think it's desirable that interfaces be documented in two
places.  The documentation which you have at the definition site is
more complete than this, and is at the place where people will expect
to find it.



bool?  If you like that sort of thing.  It makes sense here...


So maybe just nuke it and open-code those two lines in mm/migrate.c?


It would be neater if the arguments to the two versions of
mlock_migrate_page() had the same names.


That's a useful comment.

Where would the reader (and indeed the reviewer) go to find out about
"lazy mlocking"?  "grep -i 'lazy mlock' */*.c" doesn't work...


typo


When I review code I often come across stuff which I don't understand
(at least, which I don't understand sufficiently easily).  So I'll ask
questions, and I do think the best way in which those questions should
be answered is by adding a code comment to fix the problem for ever.

When I look at the isolate_lru_page()-failed cases above I wonder what
just happened.  We now have a page which is still on the LRU (how did
it get there in the first place?). Well no.  I _think_ what happened is
that this function is using isolate_lru_page() and putback_lru_page()
to move a page off a now-inappropriate LRU list and to put it back onto
the proper one.  But heck, maybe I just don't know what this function
is doing at all?

If I _am_ right, and if the isolate_lru_page() _did_ fail (and under
what circumstances?) then...  what?  We now have a page which is on an
inappropriate LRU?  Why is this OK?  Do we handle it elsewhere?  How?

etc.


extra tab.


page()?


"unlock"?  (See exhasperated comment against try_to_unlock(), below)


OK, you officially lost me here.  Two hours are up and I guess I need
to have another run at [patch 17/25]

I must say that having tried to absorb the above, my confidence in the
overall correctness of this code is not great.  Hopefully wrong, but
gee.


Doesn't mlock already do a make_pages_present(), or did that get
removed and moved to here?


Good assumption, that ;)


Could be moved outside the loop I guess.


Ditto.


The (void) is un-kernely.


random newline.


Invert the `if' expression, remove the goto?


I think kerneldoc will barf over the newline in @page's description.


OK, this function is clear as mud.  My first reaction was "what's wrong
with just doing unlock_page()?".  The term "unlock" is waaaaaaaaaaay
overloaded in this context and its use here was an awful decision.

Can we please come up with a more specific name and add some comments
which give the reader some chance of working out what it is that is
actually being unlocked?


hm, so the old definition of VM_SPECIAL managed to wedge itself between
is_mergeable_vma() and is_mergeable_vma()'s comment.  Had me confused
there.

pls remove the blank line between the comment and the start of
is_mergeable_vma() so people don't go sticking more things in there.



--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH -mm 17/25] Mlocked Pages are non-reclaimable, Rik van Riel, (Fri Jun 6, 1:28 pm)
Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable, Andrew Morton, (Fri Jun 6, 6:07 pm)
Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable, KOSAKI Motohiro, (Fri Jun 6, 10:38 pm)
Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable, Rik van Riel, (Tue Jun 10, 5:50 am)
Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable, Rik van Riel, (Tue Jun 10, 2:14 pm)
Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable, Lee Schermerhorn, (Tue Jun 10, 2:43 pm)
Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable, Andrew Morton, (Tue Jun 10, 2:57 pm)
Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable, Rik van Riel, (Tue Jun 10, 4:48 pm)
Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable, Rik van Riel, (Tue Jun 10, 6:00 pm)
Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable, Lee Schermerhorn, (Wed Jun 11, 8:29 am)
Re: [PATCH -mm 17/25] Mlocked Pages are non-reclaimable, Lee Schermerhorn, (Wed Jun 11, 9:01 am)