linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Neuling <mikey@neuling.org>
To: Milton Miller <miltonm@bga.com>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org
Subject: Re: [PATCH] SLB shadow buffer
Date: Mon, 07 Aug 2006 15:55:37 +1000	[thread overview]
Message-ID: <20060807055538.A5386679E7@ozlabs.org> (raw)
In-Reply-To: <111547573996b8b45671.846930886.miltonm@bga.com>

> > +#define SHADOW_SLB_BOLTED_LAST_ESID \
> > +		(SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1))
> > +#define SHADOW_SLB_BOLTED_LAST_VSID \
> > +		(SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1) + 8)
> 
> It's not because it's the last one but that it's the one with the stack.

Yep changed to SHADOW_SLB_BOLTED_STACK_<blah>

> > +  	std     r12,SHADOW_SLB_BOLTED_LAST_ESID(r9) /* Clear ESID */
> > +	std     r7,SHADOW_SLB_BOLTED_LAST_VSID(r9)  /* Save VSID */
> > + 	std     r0,SHADOW_SLB_BOLTED_LAST_ESID(r9)  /* Save ESID */
> > +
> 
> Tabs not spaces please

Oops.. done

> > +/*
> > + * 3 persistent SLBs are registered here.  The buffer will be zero
> > + * initially, hence will all be invaild until we actually write them.
> > + */
> > +struct slb_shadow_buffer slb_shadow_buffer[] = {
> > +	[0 ... (NR_CPUS-1)] = {
> > +		.persistent = SLB_NUM_BOLTED,
> > +		.buffer_length = sizeof(struct slb_shadow_buffer),
> > +	},
> > +};
> 
> How about making this per-cpu and setting the paca pointer at runtime?
> It would save NR_CPUS-1 cachelines of data.   Otherwise, put  in
> cacheline_aligned will potentially save some space.

The PAPR requirement is that it's cache aligned so I've added the
necessary  __cacheline_aligned foo.

I did some experiments and without the alignment.  Alignment costs
around 8KB when NR_CPUS=128 so there is some space to be saved if we
play around.

I also tried putting the structure directly in the PACA but I couldn't
get any savings.  I tired in a few different locations in the paca
struct, but it didn't make any difference.  I may have been doing
something stupid though :-)

> 
> > +
> >  /* The Paca is an array with one entry per processor.  Each contains an
> >   * lppaca, which contains the information shared between the
> >   * hypervisor and Linux.
> > @@ -59,7 +71,8 @@ struct lppaca lppaca[] = {
> >  	.lock_token = 0x8000,						    \
> >  	.paca_index = (number),		/* Paca Index */		    \
> >  	.kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL,		    \
> > -	.hw_cpu_id = 0xffff,
> > +	.hw_cpu_id = 0xffff,						    \
> > +	.slb_shadow_buffer_ptr = &slb_shadow_buffer[number]
> 
> Trailing , (yeah, still have to add the \ )

Oops.. done

> 
> >  
> >  #ifdef CONFIG_PPC_ISERIES
> >  #define PACA_INIT_ISERIES(number)					    \
> > Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
> > ===================================================================
> > --- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
> > +++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
> > @@ -22,6 +22,8 @@
> >  #include <asm/paca.h>
> >  #include <asm/cputable.h>
> >  #include <asm/cacheflush.h>
> > +#include <asm/smp.h>
> > +#include <linux/compiler.h>
> >  
> >  #ifdef DEBUG
> >  #define DBG(fmt...) udbg_printf(fmt)
> > @@ -50,9 +52,29 @@ static inline unsigned long mk_vsid_data
> >  	return (get_kernel_vsid(ea) << SLB_VSID_SHIFT) | flags;
> >  }
> >  
> > +static inline void slb_shadow_update(unsigned long esid, unsigned long vsi
d,
> > +				     unsigned long entry)
> > +{
> > +	/* Clear the ESID first so the entry is not valid while we are
> > +	 * updating it.  Then write the VSID before the real ESID. */
> 
> Multi-line comments get the  */ on it's own line

Ok... (most comments in that file are like this though)

> > +	get_slb_shadow_buffer()->save_area[2*entry] = 0;
> > +	barrier();
> > +	get_slb_shadow_buffer()->save_area[2*entry+1] =	vsid;
> > +	barrier();
> > +	get_slb_shadow_buffer()->save_area[2*entry] = esid;
> > +
> > +}
> 
> This 2* seems magic.  How about an array of structs?

OK, that's two people I've confused.  Changed.

> 
> > +
> >  static inline void create_slbe(unsigned long ea, unsigned long flags,
> >  			       unsigned long entry)
> 
> Should we rename to create_shadowed_slbe?

Good point. Changed


> > +	slb_shadow_update(mk_esid_data(ea, entry),
> > +			  mk_vsid_data(ea, flags),
> > +			  entry);
> 
> Do we need the third line?

Nope.

> 
> > +
> >  	asm volatile("slbmte  %0,%1" :
> >  		     : "r" (mk_vsid_data(ea, flags)),
> >  		       "r" (mk_esid_data(ea, entry))
> 
> Hopefully the compiler only calculates these once.

I've been keeping all my fingers and toes crossed...

> > @@ -77,6 +99,11 @@ void slb_flush_and_rebolt(void)
> >  	if ((ksp_esid_data & ESID_MASK) == PAGE_OFFSET)
> >  		ksp_esid_data &= ~SLB_ESID_V;
> >  
> > +	/* Only second entry may change here so only resave that */
> > +	slb_shadow_update(ksp_esid_data,
> > +			  mk_vsid_data(ksp_esid_data, lflags),
> > +			  2);
> > +
> 
> 1) it's the third entry 2) it's the stack slot

Yep.  Updated comment.

> 
> >  	asm volatile("isync\n"
> > Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
> > ===================================================================
> > --- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/lpar.c
> > +++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
> > @@ -254,18 +254,32 @@ out:
> >  void vpa_init(int cpu)
> >  {
> >  	int hwcpu = get_hard_smp_processor_id(cpu);
> > -	unsigned long vpa = __pa(&lppaca[cpu]);
> > +	unsigned long vpa;
> 
> This is used for something  other than vpa, rename.

Another complaint about this, I'll changed.

BTW It's called vpa in the PAPR for both calls.

> > +/* SLB shadow buffer structure as defined in the PAPR.  The save_area
> > + * contains adjacent ESID and VSID pairs for each shadowed SLB.  The
> > + * ESID is stored in the lower 64bits, then the VSID.  NOTE: This
> > + * structure is 0x40 bytes long (with 3 bolted SLBs), but PHYP
> > + * complaints if we're not 0x80 (cache line?) aligned.  */
> 
> Own line
> 
> Less explaination needed with array of structs.

Yep and yep.

> 
> > +struct slb_shadow_buffer {
> > +	u32	persistent;		// Number of persistent SLBs	x00-x03
> > +	u32	buffer_length;		// Total shadow buffer length	x04-x07
> > +	u64	reserved;		// Alignment			x08-x0f
> > +	u64     save_area[SLB_NUM_BOLTED * 2];	//			x10-x40
> > +} __attribute__((__aligned__(0x80)));
> > +
> > +extern struct slb_shadow_buffer slb_shadow_buffer[];
> > +
> 
> Remove buffer from these names? They seem quite long for linux.

Ok.  Changed.

> >  	u64 user_time;			/* accumulated usermode TB ticks */
> >  	u64 system_time;		/* accumulated system TB ticks */
> >  	u64 startpurr;			/* PURR/TB value snapshot */
> > +
> > +	/* Pointer to SLB shadow buffer */
> > +	struct slb_shadow_buffer *slb_shadow_buffer_ptr;
> >  };
> 
> With the long name the comment doesn't add much.

True.  The comment was only there since most other items in that struct
were documented.

Thanks for the review.  I'll repost the updated patch.

Mikey

  reply	other threads:[~2006-08-07  5:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-05  5:56 [PATCH] SLB shadow buffer Milton Miller
2006-08-07  5:55 ` Michael Neuling [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-08-08  4:29 Michael Neuling
2006-08-08  1:15 Milton Miller
2006-08-08  4:21 ` Michael Neuling
2006-08-07  6:19 Michael Neuling
2006-08-05 21:18 Milton Miller
2006-08-06  1:27 ` Michael Neuling
2006-08-04  5:53 Michael Neuling
2006-08-05 12:45 ` Christoph Hellwig
2006-08-09 11:22   ` Benjamin Herrenschmidt
2006-08-09 13:01     ` Segher Boessenkool

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060807055538.A5386679E7@ozlabs.org \
    --to=mikey@neuling.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=miltonm@bga.com \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).