lkml.org 
[lkml]   [2000]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [lkml]Re: VM problems still in 2.2.18
On Fri, Dec 15, 2000 at 05:57:18PM +0000, Alan Cox wrote:
> How hard is it to seperate losing kpiod (optimisation) from the MAP_SHARED
> changes ? I am assuming they are two seperate issues, possibly wrongly

Losing kpiod isn't an optimization ;(. Losing kpiod is the MAP_SHARED bugfix.

The problem was:

o swap_out
o wants to flush a MAP_SHARED dirty page to disk
o so allocate kpiod-struct
o sumbit the page-flush request to kpiod
o don't wait I/O completion to avoid deadlocking on the i_sem
o swap_out returns 1 and memory balancing code so thinks we did progress
in freeing memory and goes to allocate memory from the freelist
without waiting I/O completion
o repeat N times the above

o in the meantime kpiod has a big queue but it's blocked slowly writing
those pages to disk
o while it writes a few pages swap_out floods again the queue
without waiting and it empties the freelist (task killed)

The problem was the lack of write throttling due the kpiod async-only nature.

> Providing no inode semaphore is upped from a different task , which seems
> currently quite a valid legal thing to do (ditto doing the up on completion of
> something in bh or irq context)

Yes, the same `current' context must run the down/up pair of calls and as you
said it is legal to rely on it on all the places it's used.

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

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