All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: David Howells <dhowells@redhat.com>,
	Linus Torvalds <torvalds@transmeta.com>,
	davidm@hpl.hp.com, "David S. Miller" <davem@redhat.com>,
	anton@samba.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] move task_struct allocation to arch
Date: Fri, 15 Feb 2002 08:51:39 -0500	[thread overview]
Message-ID: <3C6D126B.E5B4810A@mandrakesoft.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0202151439160.1001-100000@serv>

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

  reply	other threads:[~2002-02-15 13:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-14 15:26 [PATCH] move task_struct allocation to arch David Howells
2002-02-14 16:13 ` Jeff Garzik
2002-02-14 16:32   ` David Howells
2002-02-14 16:46     ` Jeff Garzik
2002-02-14 17:03       ` David Howells
2002-02-14 20:48         ` Roman Zippel
2002-02-14 23:53         ` Richard Henderson
2002-02-15  9:56         ` Jeff Garzik
2002-02-15 10:01           ` Jeff Garzik
2002-02-15 11:25           ` Roman Zippel
2002-02-15 11:37             ` David Howells
2002-02-15 12:20               ` Roman Zippel
2002-02-15 12:56                 ` David Howells
2002-02-15 13:49                   ` Roman Zippel
2002-02-15 13:51                     ` Jeff Garzik [this message]
2002-02-15 14:22                       ` Roman Zippel
2002-02-15 14:07                     ` David Howells
2002-02-15 14:28                       ` Roman Zippel
2002-02-15 21:56                       ` Richard Henderson
2002-02-15 21:52                   ` Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C6D126B.E5B4810A@mandrakesoft.com \
    --to=jgarzik@mandrakesoft.com \
    --cc=anton@samba.org \
    --cc=davem@redhat.com \
    --cc=davidm@hpl.hp.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    --cc=zippel@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.