On Wed, Dec 27 2000, David Mansfield wrote:
> > In principle it looks ok, but after some time we are bound to fail 8
> > frame allocations anyway and this patch won't help. For the modular
> > case, preallocation of a bigger chunk at init time is no good either.
> > Builtin would be fine of
Jens Axboe wrote:
>
> In principle it looks ok, but after some time we are bound to fail 8
> frame allocations anyway and this patch won't help. For the modular
> case, preallocation of a bigger chunk at init time is no good either.
> Builtin would be fine of course. This almost screams sg to me
Jens Axboe wrote:
In principle it looks ok, but after some time we are bound to fail 8
frame allocations anyway and this patch won't help. For the modular
case, preallocation of a bigger chunk at init time is no good either.
Builtin would be fine of course. This almost screams sg to me :-)
On Wed, Dec 27 2000, David Mansfield wrote:
In principle it looks ok, but after some time we are bound to fail 8
frame allocations anyway and this patch won't help. For the modular
case, preallocation of a bigger chunk at init time is no good either.
Builtin would be fine of course. This
On Tue, Dec 26 2000, David Mansfield wrote:
> > > > The cdrom changes that went into test13-pre2 really kill the performance
> > > > of my cdrom. I'm using cdparanoia to read audio data, and it normally
>
> ... cut ...
>
> > Anyway, do you think a 'try to allocate 8, if that fails, try to
> >
> > >
> > > The cdrom changes that went into test13-pre2 really kill the performance
> > > of my cdrom. I'm using cdparanoia to read audio data, and it normally
... cut ...
> Anyway, do you think a 'try to allocate 8, if that fails, try to
> allocate 1' solution would be a simple compromise?
Jens Axboe wrote:
>
> On Fri, Dec 22 2000, David Mansfield wrote:
> > Jens,
> >
> > The cdrom changes that went into test13-pre2 really kill the performance
> > of my cdrom. I'm using cdparanoia to read audio data, and it normally
> > reads at 2-3x. Since test13-pre2 it's down to .6 - .7x.
Jens Axboe wrote:
On Fri, Dec 22 2000, David Mansfield wrote:
Jens,
The cdrom changes that went into test13-pre2 really kill the performance
of my cdrom. I'm using cdparanoia to read audio data, and it normally
reads at 2-3x. Since test13-pre2 it's down to .6 - .7x. I've reverted
The cdrom changes that went into test13-pre2 really kill the performance
of my cdrom. I'm using cdparanoia to read audio data, and it normally
... cut ...
Anyway, do you think a 'try to allocate 8, if that fails, try to
allocate 1' solution would be a simple compromise? That should
On Tue, Dec 26 2000, David Mansfield wrote:
The cdrom changes that went into test13-pre2 really kill the performance
of my cdrom. I'm using cdparanoia to read audio data, and it normally
... cut ...
Anyway, do you think a 'try to allocate 8, if that fails, try to
allocate 1'
On Fri, Dec 22 2000, David Mansfield wrote:
> Jens,
>
> The cdrom changes that went into test13-pre2 really kill the performance
> of my cdrom. I'm using cdparanoia to read audio data, and it normally
> reads at 2-3x. Since test13-pre2 it's down to .6 - .7x. I've reverted
> the following
On Fri, Dec 22 2000, David Mansfield wrote:
Jens,
The cdrom changes that went into test13-pre2 really kill the performance
of my cdrom. I'm using cdparanoia to read audio data, and it normally
reads at 2-3x. Since test13-pre2 it's down to .6 - .7x. I've reverted
the following files to
12 matches
Mail list logo
