Date:	Mon,  7 Apr 2008 15:02:45 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Frank Mayhar <fmayhar@...gle.com>
Cc:	frank@...t.com, linux-kernel@...r.kernel.org
Subject: Re: posix-cpu-timers revamp

> This is one thing that has been unclear.  The relationship of
> signal_struct to task_struct is, as far as I can tell, an unwritten one.

It's written no less than most of them. ;-)

> While true, that's not the only reason to do it.  The tradeoff here is
> between performance (i.e. having to do checks before dereferencing
> tsk->signal) versus space.  It's really a judgment call.  (Although
> adding 100Kwords does have a bit of weight.)

No, the performance idea there is a myth.  You're talking about one test
and branch-not-taken for a word you're already loading into a register
right there anyway (if testing ->signal).  It's maybe two cycles that were
most likely already idle in a load stall.  The cache effects alone of
pushing parts of task_struct a word further away probably swamp it.

> This isn't exactly how I would state it but yes, this is generally true
> as well.  The problem is that knowing exactly what is "the wrong kinds"
> relies on knowledge possessed by only a few.  Prying that knowledge out
> of you guys can be a chore. :-)

But when it comes out, it's flying at high velocity straight into your face!
Surely that's helpful.

> I guess the key bit of knowledge is that a "task" is really a scheduling
> unit, right?  And, really, from the scheduler's perspective, "task" is
> the same as "thread."  

Yes (and from the general Unix-lingo perspective too).  

> The only thing that makes a set of threads into a multithreaded process
> is that they share a signal struct (well, and their memory map, of
> course).  

There are several other things that are implicitly required to be shared
when signal_struct is shared, too.  But approximately, yes.  Had I been in
charge of the world, task_struct would be 'struct thread' and signal_struct
would be 'struct process'.  (Cue left-field flames from the peanut gallery
about what the words mean and Linux exceptionalism.)

> So a "task" can only be executed on a single cpu at any time, it can't be
> executed on more than one cpu at a time.  Therefore if a "task" is
> executing and is interrupted, the value of "current" at the interrupt
> will be that task, which is entirely suspended for the duration of the
> interrupt.

Correct.

> Unfortunately, these things are often implicit in the code but as far as
> I know aren't written down anywhere.  This whole exercise has been for
> me a process of becoming really familiar with the internals of the Linux
> kernel for the first time.

Everything I know I learned from reading the source.  So I sympathize
with the sense of starting out lost without bearings, but I may be a
little hard-hearted about anyone wanting more than their eyeballs and
full-text searching to find their own bootstraps and pull (in my day,
it was up hill both ways, and all that).


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists