Date: Wed, 22 Dec 2010 12:02:02 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r216634 - in head/sys/amd64: amd64 ia32 include linux32 Message-ID: <201012221202.07774.jkim@FreeBSD.org> In-Reply-To: <201012220803.12023.jhb@freebsd.org> References: <201012220018.oBM0IgOg079632@svn.freebsd.org> <201012220803.12023.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 22 December 2010 08:03 am, John Baldwin wrote: > On Tuesday, December 21, 2010 7:18:42 pm Jung-uk Kim wrote: > > Author: jkim > > Date: Wed Dec 22 00:18:42 2010 > > New Revision: 216634 > > URL: http://svn.freebsd.org/changeset/base/216634 > > > > Log: > > Improve PCB flags handling and make it more robust. Add two > > new functions for manipulating pcb_flags. These inline functions > > are very similar to atomic_set_char(9) and atomic_clear_char(9) > > but without unnecessary LOCK prefix for SMP. Add comments about > > the rationale[1]. Use these functions wherever possible. > > Although there are some places where it is not strictly necessary > > (e.g., a PCB is copied to create a new PCB), it is done across > > the board for sake of consistency. Turn pcb_full_iret into a PCB > > flag as it is safe now. Move rarely used fields before pcb_flags > > and reduce size of pcb_flags to one byte. Fix some style(9) nits > > in pcb.h while I am in the neighborhood. > > > > Reviewed by: kib > > Submitted by: kib[1] > > MFC after: 2 months > > Is there really a need to have the flags field be a char instead of > an int or long? It seems to me that flags fields in general should > be an int unless there is a strong need otherwise (e.g. > hardware-defined flag). 'orl' will work just as well as 'orb'. Actually, there was little disagreement between kib and me and committed version was fifth reincarnation of original patch. I originally used 'u_int pcb_flags' but used byte byte opcodes for assembly to make it consistent with compiler generated code. kib disliked the inconsistencies and told me to reconsider. After several versions, I proposed we use char and move forward for now, then we increase the size if it ever grows more than 8 bits. So, we settled. I have no problem with int version if there is no measurable performance change. I'll test it soon. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012221202.07774.jkim>