Messages in this thread |  | | From | Kai Harrekilde-Petersen <> | Subject | Re: Please don't beat me up (was Re: Bugs and wishes in memory management area) | Date | 28 Nov 1996 09:37:34 +0100 |
| |
smurf@noris.de (Matthias Urlichs) writes:
> In linux.dev.kernel, article > <Pine.LNX.3.95.961127160222.2744A-100000@pc5829.hil.siemens.at>, > Ingo Molnar <mingo@pc5829.hil.siemens.at> writes: > > i dont get it [it must be me]. How would you allocate 2 consecutive pages > > in this 5-page pool which has 3 free pages? : > > > > page 1 -------> free > > page 2 -------> used by the Ethernet driver > > page 3 -------> free > > page 4 -------> used by the SCSI driver > > page 5 -------> free > > > You don't. But then you don't need to. The problem is that under the > current system, things like > > page 0 -------> used by the Ethernet driver > page 1 -------> free > page 2 -------> free > page 3 -------> used by the SCSI driver > page 4 -------> free [snip] > So the new system instantly allows you to allocate a lot more pages. That > might be enough, statistically, if you always reserve a certain percentage > of pages for GPF_ATOMIC (or was that GFP_ATOMIC?) allocations.
Yes, but we still be to be able to distinguish between blocks of size 2^N*PAGESIZE that are aligned on a 2^N*PAGE_SIZE boundary and those that aren't (for DMA buffers, we don't want to cross 2^N boundaries -- especially the infamous 64Kb and 128Kb boundaries).
Duh, I guess we could solve this by passing on a 'dont_cross_this_boundary' value (if zero, no alignment is required).
Kai -- Kai Harrekilde-Petersen <khp@dolphinics.no> http://www.dolphinics.no/~khp/ Yamaha XT600Z `88 Ténéré DoD#3110 DoDK#2 UiOMC MCEK NMCU MCTC "Argue for your limitations, and sure enough - they're yours". Richard Bach
|  |