svn commit: r235480 - in stable/9/sys: dev/usb geom geom/mountver i386/conf kern sys

[Attilio Rao]

2012/5/15 Konstantin Belousov <kostikbel at gmail.com>:
> On Tue, May 15, 2012 at 11:08:37PM +0300, Andriy Gapon wrote:
>> on 15/05/2012 21:27 Konstantin Belousov said the following:
>> > On Tue, May 15, 2012 at 05:21:47PM +0000, Andriy Gapon wrote:
>> >> Author: avg Date: Tue May 15 17:21:46 2012 New Revision: 235480 URL:
>> >> http://svn.freebsd.org/changeset/base/235480
>> >>
>> >> Log: MFC r230643: stop_scheduler -> td_stopsched Modified:
>> >> stable/9/sys/sys/proc.h
>> >> ==============================================================================
>> >>
>> >>
>> --- stable/9/sys/sys/proc.h   Tue May 15 17:11:00 2012        (r235479)
>> >> +++ stable/9/sys/sys/proc.h        Tue May 15 17:21:46 2012        (r235480) @@ -235,6
>> >> +235,7 @@ struct thread { short            td_locks;       /* (k) Count of non-spin
>> >> locks. */ short            td_rw_rlocks;   /* (k) Count of rwlock read locks. */
>> >> short              td_lk_slocks;   /* (k) Count of lockmgr shared locks. */ +      short
>> >> td_stopsched;      /* (k) Scheduler stopped. */ struct turnstile *td_blocked;
>> >> /* (t) Lock thread is blocked on. */ const char    *td_lockname;   /* (t) Name
>> >> of lock blocked on. */ LIST_HEAD(, turnstile) td_contested;        /* (q)
>> >> Contested locks. */
>> >>
>> > Did you verified that there is a gap between td_lk_slocks and td_blocked an
>> > all tier-1 architectures large enough to adopt td_stopsched without
>> > changing the layout of struct thread after the new member ?
>>
>> I haven't verified that. but I presumed that the gap was either 2 bytes on
>> 32-bit architectures or 6 bytes on 64-bit ones.
>> What is the proper and doable way of verifying this?
> I think that p sizeof(struct thread) from gdb on previous and current
> version of the kernel would be a good indicator. If sizes differ, it is
> bad.
>
> To be completely sure, calculate offset of the next member in the structure:
> in gdb,
> p &(((struct thread *)0)->td_blocked)
> for previous and current kernels.
>
>>
>> > If not, this breaks KBI.
>>
>> I can just revert the commit to not risk an obscure breakage.
>> What would you suggest?
> Move the new member to the end of the struct thread, and do explicit
> zeroing on the thread allocation, if commit changed the layout.

That member position is strategic. It is left as close as possible to
the recurse flags because they will very likely be already cached when
td_schedstop is hit, which means td_schedstop will be already cached
likely and this will avoid to pollute an extra cache line.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein