On Sat, 28 Apr 2007 11:21:17 +0100 Alan Cox <[EMAIL PROTECTED]> wrote:
> > > Also remember that even if you do larger pages by using virtual pairs or
> > > quads of real pages because it helps on some systems you end up needing
> > > the same sized sglist as before so you don't make anything worse
Eric W. Biederman wrote:
>
> I have a hard time believe that device hardware limits don't allow them
> to have enough space to handle larger requests. If so it was a poor
> design by the hardware manufacturers.
>
In the MMC layer, the block size is a major bottle neck. None of the currently
sup
> But all (both) the proposals we're (ahem) discussing do involve 4x
> physically contiguous pages going into those four contiguous pagecache
> slots.
>
> So we're improving things for the half-assed controllers, aren't we?
Not neccessarily. If you use 16K contiguous pages you have to do
more wor
On Sat, 28 Apr 2007 10:04:08 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>> only 4.4 times faster, and more scalable, since we don't bounce the
>> upper level locks around.
On Sat, Apr 28, 2007 at 01:22:51AM -0700, Andrew Morton wrote:
> I'm not sure what we're looking at here. radix-tree cha
On Sat, Apr 28, 2007 at 12:29:08PM +0100, Alan Cox wrote:
> Not neccessarily. If you use 16K contiguous pages you have to do
> more work to get memory contiguously and you have less cache efficiency
> both of which will do serious damage to performance with poor I/O
> subsystems for all the extra p
Pierre Ossman <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> I have a hard time believe that device hardware limits don't allow them
>> to have enough space to handle larger requests. If so it was a poor
>> design by the hardware manufacturers.
>>
>
> In the MMC layer, the block s
On Wednesday 25 April 2007 01:21, [EMAIL PROTECTED] wrote:
> Rationales:
>
> 1. We have problems supporting devices with a higher blocksize than
>page size. This is for example important to support CD and DVDs that
>can only read and write 32k or 64k blocks. We currently have a shim
>l
On Sat, 28 Apr 2007 07:09:07 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
> On Sat, 28 Apr 2007 10:04:08 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> >> only 4.4 times faster, and more scalable, since we don't bounce the
> >> upper level locks around.
>
> On Sat, Apr 28, 2007 at 0
On Sat, 28 Apr 2007 07:09:07 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
>> The gang allocation affair would may also want to make the calls into
>> the page allocator batched. For instance, grab enough compound pages to
>> build the gang under the lock, since we're going to blow the pe
On Sat, 28 Apr 2007 12:19:56 -0700 William Lee Irwin III <[EMAIL PROTECTED]>
wrote:
> I'm skeptical, however, that the contiguity gains will compensate for
> the CPU required to do such with the pcp lists.
It wouldn't surprise me if approximate contiguity is a pretty common case
in the pcp lists
On Sat, 2007-04-28 at 01:55 -0700, Andrew Morton wrote:
> On Sat, 28 Apr 2007 10:32:56 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 2007-04-28 at 01:22 -0700, Andrew Morton wrote:
> > > On Sat, 28 Apr 2007 10:04:08 +0200 Peter Zijlstra <[EMAIL PROTECTED]>
> > > wrote:
> > >
> >
On Thu, Apr 26, 2007 at 02:28:46PM +0100, Alan Cox wrote:
> > > Oh we have scores of these hacks around. Look at the dvd/cd layer. The
> > > point is to get rid of those.
> >
> > Perhaps this is just a matter of cleaning them up so they are no
> > longer hacks?
>
> CD and DVD media support vario
On Thu, 26 Apr 2007, Andrew Morton wrote:
> > Sure, that addresses the larger I/O side of things, but it doesn't address
> > the large filesystem blocksize issues that can only be solved with some kind
> > of page aggregation abstraction.
>
> a) That wasn't a part of Christoph's original rational
201 - 213 of 213 matches
Mail list logo
