lkml.org 
[lkml]   [1996]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Please don't beat me up (was Re: Bugs and wishes in memory management area)
Date

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

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.045 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site