svn commit: r216634 - in head/sys/amd64: amd64 ia32 include
jkim at FreeBSD.org
Wed Dec 22 17:02:18 UTC 2010
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. 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
> > 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.
More information about the svn-src-all