lkml.org 
[lkml]   [2008]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: posix-cpu-timers revamp
Date
> 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


\
 
 \ /
  Last update: 2008-04-08 00:05    [W:0.259 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site