Messages in this thread | | | Date | Fri, 15 Dec 2000 19:22:07 +0100 | From | Andrea Arcangeli <> | Subject | Re: [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/
| |