Re: [PATCH 0 of 4] Generic AIO by scheduling stacks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Does that mean that we might not have some cases where we'd need to make
sure we do things differently? Of course not. Something migt show up.

Might, and has. For a good time, take journal_info out of per_call_chain() in the patch set and watch it helpfully and loudly wet itself. There really really are bits of thread_struct which are strictly thread-local-storage, of a sort, for a kernel call path. Sharing them, even only through cooperate scheduling, is fatal. link_count is another obvious one.

They're also the only ones I've bothered to discover so far :).

But
this actually makes it very clear what the difference between "struct
thread_struct" and "struct task_struct" are. One is shared between
fibrils, the other isn't.

Indeed.

Right now the per-fibril uses of task_struct members are left inline in task_struct and are copied on fibril switches.

We *could* put them in thread_info, at the cost of stack pressure, or hang them off task_struct in their own struct to avoid the copies, at the cost of indirection. I didn't like imposing a cost on paths that don't use fibrils, though, so I left them inline.

(I think you know all this. I'm clarifying for the peanut gallery, I hope.)

- z
-
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]
  Powered by Linux