preemptible kernel and dma (?)
 

Hi all,

I noticed this strange thing. Running mandrake 9.1 and I compiled kernel2.6.3 with the preemptible kernel enabled. What I noticed is that DVD playback got very choppy in xine, just as if I hadn't enabled dma on the drive (/dev/hdc). But hdparm told me that dma was enabled on the drive. After fiddling for a while (I recompiled xine against the new kernel; didn't bother with recompiling X though since it would take too long) and not finding a solution, I recompiled the kernel with preemption disabled. Now DVD playback is smooth again. I'm not sure if this a dma issue or something else that interferes with smooth reading from the drive when preemption is enabled. Has anyone else seen something like this?

:confused: very strange problem :confused:
I'm not a Linux master, but I think it comes from something else. For example, in RTLinux you have to disable APM support to avoid similar problems.
For my own, I use a 2.4.23 kernel with low latency patch and I never had such problems

I'm not too familiar with Mandrake itself, but I have heard of this dilemma with 2.6.x kernels and music/video playback. The problem is usually traceable down to the scripts your distro uses to start XFree86. Some distros (possibly Mandrake) increase the interactivity of X by increasing it's process priority using nice (i.e. nice -10 startx, etc.) With the preemptible kernel option and O(1) scheduler available in the 2.4.x-ck patchset and the 2.6.x stable kernel, such priority cheating is no longer necessary because the scheduler will automatically adjust and make sure your session is as interactive as possible.

You may want to do some research into Mandrake's bootscript setup to see if this is the case, then try again with CONFIG_PREEMPT=y

Just my 2KB

Mandy starts X with nice -10 in /etc/X11/xdm/Xservers

Well, then... okay! If you go in and un-nice the afforementioned Xservers script, all SHOULD be well. Strangely enough, the interactivity features of 2.6 make nice-ing X a BAD idea...

cheers guys,

I'll see if that's the problem.

hm,

actually, X is running with nice value 0. I don't use the graphical login manager so maybe this has something to do with it.
Also, the problem does feel like a problem with disk drive performance. Playing back divx files and such is perfectly smooth. It's only DVDs.

Just checked mandrake club archives, apparently they started using nice -10 for X with version 9.2. If your DVD is a combo drive that burns CDs too, you should probably check the /dev/dvd link to make sure it's pointing to the right block device. IDE-SCSI emulation is supposed to be deprecated in 2.6.x but the MDK 9.1 installer wouldn't have know that.

to know if it comes from your dvd drive or something else, you can use this tool: http://www.linuxdj.com/latency-graph/
Then stress your hard drive... look the result. Do the same with your dvd drive and compare the results :)
According to my experience (with kernel 2.4 only), graph will have numerous high spikes for stress system without DMA... for DMA drive, no more than 10 spikes in 10-20 seconds. And with preempt or low-latency patch... everything stay flat (in fact 1 or 2 little spike every 20 sec :))

Thanks guys,
the entries in /dev are ok. and I don't use ide-scsi. The problem can be 'solved' by merely swtiching to a kernel that has preemption disabled. which is very strange since if anything, I should see less trouble with preemption enabled. I'll check out the tool. thanks again.

Guess I should add that all my attempts to bypass SCSI emulation for my IDE DVD/CD-RW drive failed miserably, but I'm using 2.4.22 myself so maybe 2.6.x will do the trick. Switching to the preemptive multimedia kernel did alleviate the problem somewhat however. Anyway, SCSI emulation seems to be the real performance killer... enabling DMA is almost irrelevant if you're stuck using it. :(

the 2.6 kernel should get around the scsi emulation thing. I can burn CDs without scsi emulation these days.

With the 2.4 kernel, I could somehow fool the system into allowing me to access the drive through scsi emulation (/dev/scd0) *and* as a plain ide device (/dev/hdc). I could enable dma on /dev/hdc which helped for viewing dvds (/dev/dvd pointed to /dev/hdc), and I could burn through /dev/scd0. I'm not sure how I did it except that I was messing around with the kernel parameters. Disable ide-scsi and you get /dev/hdc. And then I enabled ide-scsi and somehow I had both devices available. I'm not sure if this can be reproduced, though.