Messages in this thread |  | | From | Roland McGrath <> | Subject | Re: posix-cpu-timers revamp | Date | Mon, 7 Apr 2008 15:02:45 -0700 (PDT) |
| |
> 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
|  |