lkml.org 
[lkml]   [2004]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Deadlock during heavy write activity to userspace NFS server on local NFS mount
> Hi!
>
> > >>On heavy write activity, allocators wait synchronously for kswapd to
> > >>free some memory. But if kswapd is freeing memory via a userspace NFS
> > >>server, that server could be waiting for kswapd, and the system seizes
> > >>instantly.
> > >>
> > >>This patch (against RHEL 2.4.21-15EL, but should apply either
> > >>literally
> > >>or conceptually to other kernels) allows a process to declare itself
> > >>as
> > >>kswapd's little helper, and thus will not have to wait on kswapd.
> > >>
> > >>
> > >
> > >Ok, but what if its memory runs out, anyway?
> > >
> > >
> > >
> > Tough. What if kswapd's memory runs out?
>
> I'd hope that kswapd was carefully to make sure that it always has
> enough pages...
>
> ...it is harder to do the same auditing with userland program.
>
> > A more complete solution would be to assign memory reserve levels below
> > which a process starts allocating synchronously. For example, normal
> > processes must have >20MB to make forward progress, kswapd wants >15MB
> > and the NFS server needs >10MB. Some way would be needed to express the
> > dependencies.
>
> Yes, something like that would be neccessary. I believe it would be
> slightly more complicated, like
>
> "NFS server needs > 10MB *and working kswapd*", so you'd need 25MB in
> fact... and this info should be stored in some readable form so that
> it can be checked.

Hi!

And if the NFS server is waiting for some lock that is held by another
process that is wating for kswapd...? It won't help.

The solution would be a limit for dirty pages on NFS --- if you say that
less than 1/8 of memory might be dirty NFS pages, than you can keep system
stable even if NFS writes starve. If you export NFS filesystem via NFSD
again, even this woudn't help, but there's no fix for this case.

Mikulas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.107 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site