> 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