Re: [Q x86-64] on kernel_eflags

[Ian Campbell]

On Tue, 2011-07-05 at 14:47 +0400, Cyrill Gorcunov wrote:
> While were looking into ret_from_fork code I somehow wondered
> about the global kernel_eflags variable here.
> 
> arch/x86/cpu/common.c
> ---------------------
> unsigned long kernel_eflags;
> 
> void __cpuinit cpu_init(void)
> {
> 	...
> 	raw_local_save_flags(kernel_eflags);
> }
> 
> arch/x86/kernel/entry_64.S
> --------------------------
> ENTRY(ret_from_fork)
> 	DEFAULT_FRAME
> 	LOCK ; btr $TIF_FORK,TI_flags(%r8)
> 	pushq_cfi kernel_eflags(%rip)
> 	popfq_cfi                               # reset kernel eflags
> 
> Every call to cpu_init renew global kernel_eflags
> and every task switching does use this variable in a
> sake of cleaning carry bit of flags register as far as
> I can tell.
> 
> Should not every cpu has own copy of kernel_eflags? Just
> to be consistent in style? Or this would be space waisting
> and an optimization is done here?

I noticed this a while ago and couldn't figure out why it was done this
way. On 32-bit the initial EFLAGS is simply hardcoded and that seems to
make sense to me since it's not clear that the specific value of EFLAGS
at the point it is saved in cpu_init() has any particular meaning.

I posted http://lkml.org/lkml/2010/2/9/155 to switch to the hardcoded
version for 64 bit too. Is it worth my rebasing and reposting that?

(http://lkml.org/lkml/2010/2/9/152 and http://lkml.org/lkml/2010/2/9/154
were followon cleanups).

Ian.

-- 
Ian Campbell
Current Noise: Kylesa - Drop Out

"... all the modern inconveniences ..."
		-- Mark Twain

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