> > On Fri, 19 Jun 1998, Alan Cox wrote:
> >
> > > http://roadrunner.swansea.uk.linux.org/jobs.shtml holds the major showstopper
> > > items for a 2.2 release, and a few other bugs indexed on a web page.
>
> I've written a piece of code to solve mlock problem.
> I'm certainly not a mm guru so the code may be wrong.
> Do people agree with the implemented approach to fix the problem?
It's looking good, but it does need a few improvements
before it's correct enough for inclusion...
> --- linux.orig/mm/mlock.c Wed Jun 17 14:57:33 1998
> +++ linux/mm/mlock.c Sun Jun 21 20:00:32 1998
This part is really looking excellent... The code
becomes more modular and more readable.
> --- linux.orig/mm/memory.c Wed Jun 17 14:57:33 1998
> +++ linux/mm/memory.c Tue Jun 23 19:06:55 1998
> @@ -918,6 +918,72 @@
> oom(tsk);
> }
>
> +/*
> + * mm semaphore and global kernel lock should be held,
> + * pages should belong to the same vma.
> + */
This part is a bit worse. For instance, how can we do a
swapout when we need more memory and kswapd can't acquire
the lock? The solution to this would be to only get the
locks for each _individual_ allocation, giving kswapd the
time to make more memory free. This should also reduce the
number of times the task is killed with Out_of_Memory (which
is _not_ the correct behaviour when we can simply swap out
something else)...
The solution to doing multiple-vma mlock() swapins can
be found in vmscan.c, fucntion swap_out_process()...
> --- linux.orig/include/linux/mm.h Wed Jun 17 14:49:08 1998
> +++ linux/include/linux/mm.h Sun Jun 21 20:27:45 1998
> @@ -292,6 +292,7 @@
No comments here, of course :-)
Keep up the good work, Andrey (the only part of your
name I can write correctly in one try :)...
grtz,
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu