On Wed, 3 Jun 2009, Eygene Ryabinkin wrote: >> This seems to be related to the recent NETISR changes, namely, the >> addition of the pc_netisr member to the struct pcpu: >> http://svn.freebsd.org/viewvc/base/head/sys/sys/pcpu.h?r1=187679&r2=193219&diff_format=u >> >> I am not sure how large (void *) is on sun4v, but it seems to me >> that it is 4 bytes long, so PCPU_MD_FIELDS_PAD inside sun4v/include/pcpu.h > ^^^^^^^^^^^^ > Sorry, eight bytes long: wrote 4, but really meant 8 ;)) > >> should be compensated for this change. Something like >> ----- >> #ifdef KTR >> #define PCPU_MD_FIELDS_PAD (3 - (PCPU_NAME_LEN + 7) / 8) >> #else >> #define PCPU_MD_FIELDS_PAD 3 >> #endif >> ----- >> though I am not very sure about KTR's case. > > KTR's case seems to be wrong for PCPU_NAME_LEN larger than 24 bytes. Just > now we won't be able to reach this with the current definition for > PCPU_NAME_LEN, but some day (N - (PCPU_NAME_LEN + 7)/8) can become negative > and that's bad. > > The attached patch should fix this (although I have no sun4v to test on, so > take it with a grain of salt). > > By the way, having looked at sys/sys/pcpu.h, I see that there are parts of > 'struct pcpu' that depend on the KTR_PERCPU being defined and they are never > compensated with padding in PCPU_MD_FIELDS for sun4v. Is KTR_PERCPU > constant for sun4v (inexisting or defined everytime) or I am missing > something? Is there a reason not just to use __aligned(64) or the like on the first entry of the MD PCPU structure for sun4v to avoid future MI pcpu changes from causing similar discomfort for the MD pcpu parts? Also, do we know why these alignment/sizing requirements exist for struct pcpu on sun4v but not other platforms? If this is about packing pcpu structures into properly aligned cache lines, again __aligned() might be the right approach to take... Robert N M Watson Computer Laboratory University of CambridgeReceived on Wed Jun 03 2009 - 18:06:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:49 UTC