Messages in this thread | | | Date | Fri, 25 May 2001 22:40:52 -0400 (EDT) | From | Ben LaHaise <> | Subject | Re: [with-PATCH-really] highmem deadlock removal, balancing & cleanup |
| |
On Sat, 26 May 2001, Andrea Arcangeli wrote:
> It does, but only for the create_bounces. As said if you want to "fix", > not to "hide" you need to address every single case, a generic reserved > pool is just useless. Now try to get a dealdock in 2.4.5 with tasks > locked up in create_bounces() if you say it does not protect against > irqs. see?
So? It just deadlocks in create_buffers/alloc_pages. We finished debugging that weeks ago, and I'm not interested in repeating that.
> What I said is that instead of handling the pool by hand in every single > place one could write an API to generalize it, but very often a simple > API hooked into the page allocator may not be flexible enough to > guarantee the kind of allocations we need, highmem is just one example > where we need more flexibility not just for the pages but also for the > bh (but ok that's mostly an implementation issue, if you do the math > right, it's harder but you can still use a generic API).
Well, this is the infrastructure for guaranteeing atomic allocations. The only beautifying it really needs is in adding an alloc_pages variant that takes the reservation pool as a parameter instead of the current mucking with current->page_reservation.
> > Re-read the above and reconsider. The reservation doesn't need to be > > permitted until after page_alloc has blocked. Heck, do a schedule before > > I don't see what you mean here, could you elaborate?
I simply meant that the reservation code wasn't bent on providing atomic allocations for non-atomic allocators. IIRC, I hooked into __alloc_pages after the normal mechanism of allocating pages failed, but where it may have already slept, but I think that was part of the other patch I posted in the last email. Our tree contains a lot of patches, and some of the effects like this are built on top of each other, so I'm not surprised that a critical piece like that was missing.
-ben
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |