[Dri-devel] Re: Feedback on preemptible kernel patch

[Robert L. <rm...@te...>]

On Sat, 2001-09-15 at 00:25, Dieter N=FCtzel wrote:
> > > >  ReiserFS may be another problem.
> > > Can't wait for that.
> Most wanted, now.

I am working on it, but I am unfamilar with it all.

Are you seeing any specific problems, now?  With the latest preemption
patch on 2.4.10-pre9, do you crash? oops?

The only outstanding issue now is ReiserFS issues.

> Tried it and it works so far.
>=20
> It seems to be that kswap put some additional "load" on the disk from tim=
e
> to time. Or is it the ReiserFS thing, again?

I don't think its related to ReiserFS.

What sort of activity are you seeing?  How often?  How do you know its
kswapd?

> Have you a copy of my posted ksymoops file?
> But the oopses seems to be cured.

Yah, I just am having a problem sorting  who said what running what and
when :)

I am glad the patch fixed it, the final version of that is going into
the next preemption patch.  Stay tuned.

> I don't know exactly 'cause kernel hacking is not my main focus.
>=20
> But have you thought about the MMX/3DNow! stuff in Mesa/OpenGL (XFree86 D=
RI)?
> And what do you think about the XFree86 Xv extentions (video) or the whol=
e=20
> MPEG2/3/4, Ogg-Vorbis, etc. (multimedia stuff)?
>=20
> Do all these libraries (progs) need some preempt patches?
> That's why I cross posted to the DRI-Devel List (sorry).

No, these are unrelated.

Sorry for the cross-post, DRI :)

The kernel takes care of saving state for FPU operations for userspace.=20
Indeed, it takes care of everything for userspace.  In kernel land, we
don't have that beauty, we have to worry about everything we do and
everything we change, and thus we have this problem.

What exactly happens is another operation is preempting the current
process during an FPU operation, when the CPU is in a different state,
and then everything barfs since it is not as it wants to be.

This is not an issue for userspace.

> I understand ;-)
> It seems to calm it.

Good.

> Now, here are my results.
> <snip>

These results are pretty good.  Throughput seems down 2-3% in many
cases, although latency is greatly improved.  Look at those latency
changes!  From thousands of ms to hundreds of us in bonnie.  Wow.

Even if you don't care about latency (I'm not an audio person or
anything), these changes should be worth it.

> Deleting with ReiserFS and the preempt kernel is GREAT!

Good. I/O latency should be great now, with little change in
throughput...

> But I get some hiccup during noatun (mp3, ogg, etc. player for KDE-2.2) o=
r=20
> plaympeg together with dbench (16, 32). ReiserFS needs some preemption
> fixes, too?

You may still get some small hiccups ( < 1 second?) even with the
preemption patch, as kernel locks prevent preemption (the patch can't
guarentee low latency, just preemption outside of the locks).

However, how bad was the hiccups with preemption disabled?  I have heard
reports where it is 3-5sec at times.

As the kernel becomes more scalable (finer-grain locking), preemption
will improve.  Past that, perhaps during 2.5, we can work on some other
things to improve preemption.

> I've attached two small compressed bonnie++ HTML files.

These were neat, thanks.

Thank you for your feedback and support.  Stay current with the kernel
and the preemption patches, and I will try to figure the ReiserFS
crashes out.

--=20
Robert M. Love
rml at ufl.edu
rml at tech9.net