On 8/8/07, Andrew Morton <[email protected]> wrote:
> On Wed, 8 Aug 2007 10:57:13 -0700 (PDT)
> Christoph Lameter <[email protected]> wrote:
>
> > I think in general irq context reclaim is doable. Cannot see obvious
> > issues on a first superficial pass through rmap.c. The irq holdoff would
> > be pretty long though which may make it unacceptable.
>
> The IRQ holdoff could be tremendous. But if it is sufficiently infrequent
> and if the worst effect is merely a network rx ring overflow then the tradeoff
> might be a good one.
Hi Andrew,
No matter how you look at this problem, you still need to have _some_
sort of reserve, and limit access to it. We extend existing methods,
you are proposing to what seems like an entirely new reserve
management system. Great idea, maybe, but it does not solve the
deadlocks. You still need some organized way of being sure that your
reserve is as big as you need (hopefully not an awful lot bigger) and
you still have to make sure that nobody dips into that reserve further
than they are allowed to.
So translation: reclaim from "easily freeable" lists is an
optimization, maybe a great one. Probably great. Reclaim from atomic
context is also a great idea, probably. But you are talking about a
whole nuther patch set. Neither of those are in themselves a fix for
these deadlocks.
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
