[lkml]   [2000]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: cdrom changes in test13-pre2 slow down cdrom access by 70%
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 almost screams sg to me :-)
> >
> Nonetheless, with your first patch and my patch, the system starts off
> using the old method of trying to allocate 8 frames buffer (which is
> essential for performance) and falls back to the current (as of
> test13-pre2) way in low/fragmented memory situations. To me, that's
> better than either the previous or the current method, with the slight
> increased cost of the failed kmalloc every time in the low/fragmented
> memory case. [...]

Yes I agree, it's better than what is there. All I was saying is that
it could be better :-). I've already put something close to your patch
in my tree, will be sent off the next time

> BTW, have you gotten reports of that kmalloc failing for people?

Of course, otherwise I wouldn't have changed it.

> I've been ripping audio with every kernel since pre4 and have
> never had a failure. Granted, I put 'workstation' loads on my machine,
> but I run some benchmarks from time-to-time, put memory pressure on
> etc. (H*ll, just netscape alone is memory pressure enough :-).

Depends on how much RAM you have, and what you are doing.

* Jens Axboe <>
* SuSE Labs
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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