lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090410094738.GA11770@elte.hu>
Date:	Fri, 10 Apr 2009 11:47:38 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Matt Helsley <matthltc@...ibm.com>, Tejun Heo <tj@...nel.org>,
	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Alexey Dobriyan <adobriyan@...il.com>, akpm@...ux-foundation.org,
	containers@...ts.linux-foundation.org, xemul@...allels.com,
	linux-kernel@...r.kernel.org, dave@...ux.vnet.ibm.com,
	hch@...radead.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH 09/30] x86_64: ifdef out struct thread_struct::ip


* Ingo Molnar <mingo@...e.hu> wrote:

> 
> * Matt Helsley <matthltc@...ibm.com> wrote:
> 
> > On Fri, Apr 10, 2009 at 06:35:22AM +0400, Alexey Dobriyan wrote:
> > > struct thread_struct::ip isn't used on x86_64, struct pt_regs::ip is used
> > > instead. 
> > > 
> > > kgdb should be reading 0, but I can't check it.
> > > 
> > > Signed-off-by: Alexey Dobriyan <adobriyan@...il.com>
> > > ---
> > > 
> > >  arch/x86/include/asm/processor.h |    2 ++
> > >  arch/x86/kernel/kgdb.c           |    2 +-
> > >  2 files changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > --- a/arch/x86/include/asm/processor.h
> > > +++ b/arch/x86/include/asm/processor.h
> > > @@ -421,7 +421,9 @@ struct thread_struct {
> > >  	unsigned short		fsindex;
> > >  	unsigned short		gsindex;
> > >  #endif
> > > +#ifdef CONFIG_X86_32
> > >  	unsigned long		ip;
> > > +#endif
> > >  #ifdef CONFIG_X86_64
> > >  	unsigned long		fs;
> > >  #endif
> > 
> > Do these make struct thread_struct behave better in cachelines 
> > (smaller, less aliasing)? Can we really fit more in the slab du 
> > jour?
> > 
> > Otherwise it seems like we're littering these structs with #ifdefs 
> > and not really saving anything. [...]
> 
> Removing fields always saves memory (even if it does not show up 
> currently due to allocators cache-aligning sizes).

I mean: we always try to consider structure size reductions as if 
they saved real memory, even if they dont do so in the current 
layout and allocation patterns.

In reality only every 8th 8-byte reduction will result in a true 
64-byte cacheline reduction - but still we have to continue small 
reductions otherwise we wont ever get to the larger reductions in 
the first place.

I.e. Alexey's patch shows a real item worth checking, regardless of 
the current size and alignment scenario.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ