Willy Tarreau <[email protected]> writes:
> On Sat, Apr 14, 2007 at 07:54:33PM +0200, Ingo Molnar wrote:
>>
>> * Eric W. Biederman <[email protected]> wrote:
>>
>> > > Thinking about it, I don't know if there are calls to schedule()
>> > > while switching from tty1 to tty2. Alt-F2 had no effect anymore, and
>> > > "chvt 2" simply blocked. It would have been possible that a
>> > > schedule() call somewhere got starved due to the load, I don't know.
>> >
>> > It looks like there is a call to schedule_work.
>>
>> so this goes over keventd, right?
>>
>> > There are two pieces of the path. If you are switching in and out of a
>> > tty controlled by something like X. User space has to grant
>> > permission before the operation happens. Where there isn't a gate
>> > keeper I know it is cheaper but I don't know by how much, I suspect
>> > there is still a schedule happening in there.
>>
>> Could keventd perhaps be starved? Willy, to exclude this possibility,
>> could you perhaps chrt keventd to RT priority? If events/0 is PID 5 then
>> the command to set it to SCHED_FIFO:50 would be:
>>
>> chrt -f -p 50 5
>>
>> but ... events/0 is reniced to -5 by default, so it should definitely
>> not be starved.
>
> Well, since I merged the fair-fork patch, I cannot reproduce (in fact,
> bash forks 1000 processes, then progressively execs scheddos, but it
> takes some time). So I'm rebuilding right now. But I think that Linus
> has an interesting clue about GPM and notification before switching
> the terminal. I think it was enabled in console mode. I don't know
> how that translates to frozen xterms, but let's attack the problems
> one at a time.
I think it is a good clue. However the intention of the mechanism is
that only processes that change the video mode on a VT are supposed to
use it. So I really don't think gpm is the culprit. However it easily could
be something else that has similar characteristics.
I just realized we do have proof that schedule_work is actually working
because SAK works, and we can't sanely do SAK from interrupt context
so we call schedule work.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
