Roman Zippel wrote:
>
> Hi,
>
> On Fri, 15 Feb 2002, David Howells wrote:
>
> > Firstly, in response to me having supplied a patch that made a set of four
> > byte-size values as the status area in the task_struct:
> >
> > | For the future, the biggest thing I'd like to see is actually to make
> > | "work" be a bitmap, because the "bytes are atomic" approach simply isn't
> > | portable anyway, so we might as well make things _explicitly_ atomic and
> > | use bit operations. Otherwise the alpha version of "work" would have to be
> > | four bytes per "bit" of information, which sounds really excessive.
>
> As I mentioned before I more like the byte approach, since atomic bit
> field handling is quite expensive on most architectures, where a simple
> set/clear byte is only one or two instructions, if there is byte
> load/store instruction. So I'd really like to see to leave the decision to
> the architecture, whether to use bit or byte fields.
We have tons of code already using atomic test_and_set_bit type
stuff... why not just make sure your bit set/clear stuff is fast? :)
Jeff
-- Jeff Garzik | "I went through my candy like hot oatmeal Building 1024 | through an internally-buttered weasel." MandrakeSoft | - goats.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 21:01:07 EST