Re: Major 2.1.x problem index

Savochkin Andrey Vladimirovich (saw@msu.ru)
Wed, 24 Jun 1998 18:18:34 +0400


On Tue, Jun 23, 1998 at 09:34:02PM +0200, Rik van Riel wrote:
> On Tue, 23 Jun 1998, Savochkin Andrey Vladimirovich wrote:
[snip]
> > --- 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)...

You speak about global kernel lock via lock_kernel, don't you?
I suppose if page isn't present the task will go sleep waiting
for IO completion the lock will be released
and kswapd will get a chance to do the job.
I don't think that giving additional chances to kswapd to work
on SMP systems is worth redesign of SMP locks in mlock.
But if people think that it is worth I'll think how to do it.

>
> The solution to doing multiple-vma mlock() swapins can
> be found in vmscan.c, fucntion swap_out_process()...

Multiple vma isn't a problem. make_pages_present is called from
mlock_fixup only for pages in the same vma. A loop for all
vma covered by user specified arguments is done by the caller of mlock_fixup.

>
> > --- 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 :)...

:-)

Best wishes
Andrey V.
Savochkin

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu