> quota drop, and that involves quota writeback if it was the last inode
> on that particular quota struct.
>
> shrinking the icache _usually_ involves no IO, but the quota case is
> an exception which a lot of developers won't encounter during testing.
We've had a history of weird quota
Hi,
On Sun, Sep 24, 2000 at 08:40:05PM +0200, Ingo Molnar wrote:
> On Sun, 24 Sep 2000, Linus Torvalds wrote:
>
> > [...] I don't think shrinking the inode cache is actually illegal when
> > GPF_IO isn't set. In fact, it's probably only the buffer cache itself
> > that has to avoid recursion -
On Sun, 24 Sep 2000, Linus Torvalds wrote:
> I think that shm_swap still needs it - it's doing things with
> rw_swap_page() that means that we cannot run it without GFP_IO.
yep - i only pushed the test inside, it's functionally equivalent - it
only vanished from refill_inactive(). It's
[ Sorry to follow up on myself.. ]
On Sun, 24 Sep 2000, Linus Torvalds wrote:
>
> Send me the tested patch (and I'd suggest moving the shm_swap() test into
> shm_swap() too, so that refill_inactive() gets cleaned up a bit).
I think that shm_swap still needs it - it's doing things with
On Sun, 24 Sep 2000, Ingo Molnar wrote:
>
> i just found this out by example, i'm running the shrink_[i|d]cache stuff
> even if __GFP_IO is not set, and no problems so far. (and much better
> balancing behavior)
Send me the tested patch (and I'd suggest moving the shm_swap() test into
On Sun, 24 Sep 2000, Linus Torvalds wrote:
> [...] I don't think shrinking the inode cache is actually illegal when
> GPF_IO isn't set. In fact, it's probably only the buffer cache itself
> that has to avoid recursion - the other stuff doesn't actually do any
> IO.
i just found this out by
On Sun, 24 Sep 2000, Ingo Molnar wrote:
>
> as a longer term solution, i'm wondering how hard it would be to propagate
> gfp_mask into the shrink_*() functions, and prevent recursion similarly to
> the swap-out logic? This way even GFP_BUFFER allocators could touch/free
> the dcache/icache.
i've seen a couple of GFP_BUFFER allocation deadlocks in an atypical
system which had lots of RAM allocated to inodes. The reason for the
deadlock is that the shrink_*() functions cannot be called if __GFP_IO is
not set. Nothing else can be freed at that point, so the try_again: loop
in
i've seen a couple of GFP_BUFFER allocation deadlocks in an atypical
system which had lots of RAM allocated to inodes. The reason for the
deadlock is that the shrink_*() functions cannot be called if __GFP_IO is
not set. Nothing else can be freed at that point, so the try_again: loop
in
On Sun, 24 Sep 2000, Ingo Molnar wrote:
as a longer term solution, i'm wondering how hard it would be to propagate
gfp_mask into the shrink_*() functions, and prevent recursion similarly to
the swap-out logic? This way even GFP_BUFFER allocators could touch/free
the dcache/icache.
Well,
On Sun, 24 Sep 2000, Linus Torvalds wrote:
[...] I don't think shrinking the inode cache is actually illegal when
GPF_IO isn't set. In fact, it's probably only the buffer cache itself
that has to avoid recursion - the other stuff doesn't actually do any
IO.
i just found this out by
On Sun, 24 Sep 2000, Ingo Molnar wrote:
i just found this out by example, i'm running the shrink_[i|d]cache stuff
even if __GFP_IO is not set, and no problems so far. (and much better
balancing behavior)
Send me the tested patch (and I'd suggest moving the shm_swap() test into
shm_swap()
[ Sorry to follow up on myself.. ]
On Sun, 24 Sep 2000, Linus Torvalds wrote:
Send me the tested patch (and I'd suggest moving the shm_swap() test into
shm_swap() too, so that refill_inactive() gets cleaned up a bit).
I think that shm_swap still needs it - it's doing things with
quota drop, and that involves quota writeback if it was the last inode
on that particular quota struct.
shrinking the icache _usually_ involves no IO, but the quota case is
an exception which a lot of developers won't encounter during testing.
We've had a history of weird quota deadlocks
14 matches
Mail list logo
