On Thu, 22 Jun 2000, Andrea Arcangeli wrote:
> On Thu, 22 Jun 2000, Rik van Riel wrote:
>
> >Ahh, but we don't have to stall. We just queue some blocks for
>
> I agree and that's why I removed it ;). The point is that
> ll_rw_block _will_ stall if there's somebody flooding writes to
> disk because there won't be any request available immediatly.
*nod* Then again, if we're in serious overload situation we
will just *have* to wait somewhere. There is no possibility
to just get some memory in a magic way.
One thing we _could_ do in shrink_mmap() is limit the number
of pages queued for flushing in one shrink_mmap() run, a'la
FreeBSD maxlaunder...
> ll_rw_block(WRITE) does async I/O only if it can.
>
> ll_rw_block(WRITEA) was used to do _always_ async I/O (that's
> why I'm saying WRITEA wouldn't had this problem) and it wasn't
> reliable.
Well, it *has* to be reliable. Otherwise we might fail to free
memory and we'll kill something with out of memory even though
we still have memory left.
(yes, write throttling is the proper solution .. does anybody
know of a nice write throttling technique (sp?) for mmap()s?)
> >The attached patch seems to fix it. With it I'm seeing higher
>
> I think your patch is ok (thanks), however I'm not sure how much
> it will affect the above scenario.
I'm not sure either. I'll experiment with some maxlaunder
logic in shrink_mmap(). If we can keep the request queue
from overflowing in almost all situations we should be able
to avoid most (all?) of the stalls.
See FreeBSD sys/vm/vm_pageout.c for more information on this
idea.
regards,
Rik
-- The Internet is not a network of computers. It is a network of people. That is its real strength.Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies http://www.conectiva.com/ http://www.surriel.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:24 EST