Daniel Phillips | 1 Aug 17:38 2003
Picon

Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches

On Saturday 26 July 2003 17:05, Ed Sweetman wrote:
> My comment was towards the fact that although playing audio is a
> realtime priority, decoding audio is not, and is not coded that way in
> many programs, in fact, many programs will sleep() in order to decode
> only when the output buffer is getting low.

Decoding is realtime too, though the bounds are more relaxed than for the DMA 
refill process.  In fact, it's the decoding task that causes skipping, 
because the DMA refill normally runs in interrupt context (so should mixing 
and equalizing, but that's another story) where essentially everything is 
realtime, modulo handwaving.

To convince yourself of this, note that when DMA refill fails to meet its 
deadline you will hear repeats, not skipping, because the DMA hardware on the 
sound card has been set up to automatically restart the DMA each time the 
buffer expires.  Try running the kernel under kgdb and breaking to the 
monitor while sound is playing.

So you need to reevaluate your thinking re the realtime nature of audio 
decoders.

To be sure, for perfect audio reproduction, any file IO involved has to be 
realtime as well, as does the block layer.  We're not really in position to 
take care of all that detail at this point, mainly because no Linux 
filesystem has realtime IO support.  (I believe Irix XFS has realtime IO and 
that part didn't get ported because of missing infrastructure in Linux.)  But 
the block layer isn't really that far away from being able to make realtime 
guarantees.  Mainly, that work translates into plugging in a different IO 
scheduler.

(Continue reading)

Robert Love | 1 Aug 01:02 2003
Picon

Re: [PATCH] protect migration/%d etc from sched_setaffinity

On Thu, 2003-07-31 at 15:46, Joe Korty wrote:

> Lock out users from changing the cpu affinity of those per-cpu system
> daemons which cannot survive such a change, such as migration/%d.
> 
> Passes basic handtest of sched_setaffinity(2) on various locked and
> unlocked processes on a i386, otherwise untested except by eyeball.
> 
> Except for one line in i386, no arch needed any changes to support
> this patch.

I have been wondering what to do about processor affinity and kernel
threads. I just concluded "only root can change it, and we can let root
stab herself if she really wants to."

But if this is really an issue, why not just do:

	ret = -EINVAL;
	if (!p->mm)
		goto out_unlock;

in sys_sched_setaffinity ?

	Robert Love

Ed Sweetman | 1 Aug 01:02 2003

Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches


What i consider decoding is everything from the file to the audio going 
to the audio device. This means moving the audio from your decoder into 
the buffer you use to play sound.  The process may be set as realtime, 
but whether or not it's able to accomplish that is up to the code 
itself, usually you have more audio experienced programmers working on 
the output library/device.  Just because the decoder may be able to get 
cpu and resources when it asks for it within a bounded range doesn't 
mean it's able to accomplish what it's supposed to within that range all 
the time.  Otherwise explain why substituting different decoders results 
in different performances regarding audio skipping, that includes 
different decoders for different codecs and even the same ones. The 
audio programs themselves are responsible for the poor performances they 
get with current kernels much more than the kernel is, that point was my 
original subject.

yea, it's just as distinct per cycle as outputting audio is, but the 
players are not at a realtime quality, which they should be before 
people start using them to grade the kernel's "realtimeness".

Daniel Phillips wrote:
> On Saturday 26 July 2003 17:05, Ed Sweetman wrote:
> 
>>My comment was towards the fact that although playing audio is a
>>realtime priority, decoding audio is not, and is not coded that way in
>>many programs, in fact, many programs will sleep() in order to decode
>>only when the output buffer is getting low.
> 
> 
> Decoding is realtime too, though the bounds are more relaxed than for the DMA 
(Continue reading)

Robert Love | 1 Aug 01:18 2003
Picon

Re: [PATCH] protect migration/%d etc from sched_setaffinity

On Thu, 2003-07-31 at 16:06, Joe Korty wrote:

> It's not all system daemons, just some of them that need protection.
> 
> Keeping the set of locked-down daemons to the smallest possible is
> important when one wants to 'set aside' cpus for use only by
> specific, need-the-lowest-latency-possible realtime applications.

Yah, I know. But this is a lot of code just to prevent root from hanging
herself, and she has plenty of other ways with which to do that.

	Robert Love

Joe Korty | 1 Aug 01:06 2003

Re: [PATCH] protect migration/%d etc from sched_setaffinity

> On Thu, 2003-07-31 at 15:46, Joe Korty wrote:
> 
> > Lock out users from changing the cpu affinity of those per-cpu system
> > daemons which cannot survive such a change, such as migration/%d.
> > 
> > Passes basic handtest of sched_setaffinity(2) on various locked and
> > unlocked processes on a i386, otherwise untested except by eyeball.
> > 
> > Except for one line in i386, no arch needed any changes to support
> > this patch.
> 
> I have been wondering what to do about processor affinity and kernel
> threads. I just concluded "only root can change it, and we can let root
> stab herself if she really wants to."
> 
> But if this is really an issue, why not just do:
> 
> 	ret = -EINVAL;
> 	if (!p->mm)
> 		goto out_unlock;
> 
> in sys_sched_setaffinity ?
> 
> 	Robert Love

It's not all system daemons, just some of them that need protection.

Keeping the set of locked-down daemons to the smallest possible is
important when one wants to 'set aside' cpus for use only by
specific, need-the-lowest-latency-possible realtime applications.
(Continue reading)

Matthew Wilcox | 1 Aug 01:14 2003
Picon

Re: [ANNOUNCE] megaraid 2.00.6 patch for kernels without hostlock

On Thu, Jul 31, 2003 at 05:10:50PM -0400, Mukker, Atul wrote:
> 
> Well, that's definitely a good idea. Expect a new driver with this change.
> BTW, is there a kernel version beyond which all versions would support per
> host lock, and I mean a 2.4.x kernel :-)

that's a pretty dangerous change to make to a stable kernel.  much better
to work on stabilising 2.6.

--

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

jw schultz | 1 Aug 01:15 2003

Re: fun or real: proc interface for module handling?

On Thu, Jul 31, 2003 at 02:34:01PM +0200, Måns Rullgård wrote:
> Nico Schottelius <nico-kernel <at> schottelius.org> writes:
> 
> > I was just joking around here, but what do you think about this idea:
> >
> > A proc interface for module handling:
> >    /proc/mods/
> >    /proc/mods/≤module-name>/<link-to-the-modules-use-us>
> >
> > So we could try to load a module with
> >    mkdir /proc/mods/ipv6
> > and remove it and every module which uses us with
> >    rm -r /proc/mods/ipv6
> 
> So far, so good.
> 
> > Modul options could be passed my
> >    echo "psmouse_noext=1" > /proc/mods/psmouse/options
> > which would also make it possible to change module options while running..
> 
> How would options be passed when loading?  Some modules require that
> to load properly.  Also, there are lots of options that can't be
> changed after loading.  To enable this, I believe the whole option
> handling would need to be modified substantially.  Instead of just
> storing the values in static variables, there would have to be some
> means of telling the module that its options changed.  Then there's
> the task of hacking all modules to support this...

How about
	ln -s noext=1,speed=6 /proc/module/psmouse
(Continue reading)

Oliver Neukum | 1 Aug 01:12 2003

Re: [linux-usb-devel] Re: OHCI problems with suspend/resume


> Is not disk spin-down policy, and thus belonging to userspace? Having
> daemon poll for inactivity of hubs once every 5 minutes and sending
> them to sleep should not hurt, too...
> 								Pavel

Taking precedents into account it is the kernel's job.
Screen blanking is done in kernel, as is afaik floppy
motor control.

	Regards
		Oliver

Joe Korty | 1 Aug 01:11 2003

Re: [PATCH] protect migration/%d etc from sched_setaffinity

> Joe Korty <joe.korty <at> ccur.com> wrote:
> >
> > Lock out users from changing the cpu affinity of those per-cpu system
> > daemons which cannot survive such a change, such as migration/%d.
> 
> Generally we prefer to not add code which purely protects root from making
> mistakes.  Once the sysadmin has nuked his box he'll learn to not do it
> again.

I'd like to be able to write shell scrips that operate on the set of
/proc/[0-9]* without having to know which of the ever-changing list
of processes need to be avoided and which not.

And it's not really root.  It's a SYS_CAP_NICE capability.  All
realtime apps or their admins will have that capability as a matter
of course in their normal daily operations.

Joe
Joe Korty | 1 Aug 01:16 2003

Re: [PATCH] protect migration/%d etc from sched_setaffinity

> Yah, I know. But this is a lot of code just to prevent root from hanging
> herself, and she has plenty of other ways with which to do that.

Actually it is only 20 lines of changes .. 16 lines added, 4 deleted.
Joe

Gmane