On Thu, Oct 13, 2016 at 4:57 AM, Heiko Carstens
<heiko.carstens@xxxxxxxxxx> wrote:
> Commit c65eacbe290b ("sched/core: Allow putting thread_info into
> task_struct") made struct thread_info a generic struct with only a
> single flags member if THREAD_INFO_IN_TASK_STRUCT is selected.
>
> This change however seems to be quite x86 centric, since at least the
> generic preemption code (asm-generic/preempt.h) assumes that struct
> thread_info also has a preempt_count member, which apparently was not
> true for x86.
>
> We could add a bit more ifdefs to solve this problem too, but it seems
> to be much simpler to make struct thread_info arch specific
> again. This also makes the conversion to THREAD_INFO_IN_TASK_STRUCT a
> bit easier for architectures that have a couple of arch specific stuff
> in their thread_info definition.
OK, I give in.
But can you coordinate with Mark, because I think I convinced him to
do it a little differently? I might be changing my mind a bit for an
evil reason. Specifically, on x86_64, we could do the following evil,
horrible thing:
union {
u64 flags;
struct {
u32 atomic_flags;
u32 nonatomic_flags;
}
};
Then we could read and test the full set of flags (currently split
between "flags" and "status") with a single instruction, and we could
set them maximally efficiently. I don't actually want to do this
right away, but making thread_info fully arch-controlled would allow
this.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
