archive mirror
 help / color / mirror / Atom feed
From: Michel Lespinasse <>
To: Mete Polat <>
Cc: Davidlohr Bueso <>, Arnd Bergmann <>,
	Lukas Bulwahn <>,
	Michel Lespinasse <>,
	Andrew Morton <>,
	Jesper Nilsson <>,
	David Woodhouse <>,
	Ingo Molnar <>,
	Peter Zijlstra <>,
	Randy Dunlap <>,,
	Linux Kernel Mailing List <>,
	Geert Uytterhoeven <>
Subject: Re: [PATCH] rbtree: remove unneeded explicit alignment in struct rb_node
Date: Fri, 6 Aug 2021 01:52:45 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <YQwd2puXiSiUWEE1@precision>

On Thu, Aug 05, 2021 at 07:20:26PM +0200, Mete Polat wrote:
> On Thu, Aug 05, 2021 at 08:02:28AM -0700, Davidlohr Bueso wrote:
> > On 2021-08-05 07:02, Arnd Bergmann wrote:
> > > The revert would appear to change the alignment to 16 bits instead
> > > of 32 bits on m68k as well (not 8 bits as on cris), but I don't know if
> > > that
> > > can cause problems there.
> > 
> > Yeah I tried this a while back and it broke m68k, so it was a no go:
> > 
> >
> The problem is that the field '__rb_parent_color' in struct rb_node is
> storing the color AND the pointer to the parent node at the same time.
> The color is stored in the least significant bit which is fine when
> rb_node is at least 16-bit aligned. I guess, it does not work on m68k
> because the makro
> #define __rb_parent(pc)    ((struct rb_node *)(pc & ~3))
> used to retrieve the parent pointer zeros the first two bits, not only
> the first one.
> Maybe the effiency to store this one color bit in another field was
> required in the early days but I think moving the color to a seperate
> field is really the better way to go. It also makes reasoning about the
> algorithm easier.
> I will create a patch.

I think moving the color to a separate word would be costly, both in space
(growing the struct rb_node) and in time. Feel free to try it, but I would
expect the rbtree performance tests to regress significantly.

__rb_parent() could probably be modified - it only needs to mask one bit,
I'm not sure why it masks two.

As to what would happen on 68k... hard to say, but I expect it should
be fine (if the compiler cared for the structs to be aligned, it
should do it on its own). Still, not sure how to test that either.

Michel "walken" Lespinasse

  reply	other threads:[~2021-08-06  8:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 13:32 [PATCH] rbtree: remove unneeded explicit alignment in struct rb_node Lukas Bulwahn
2021-08-05 14:02 ` Arnd Bergmann
2021-08-05 14:14   ` Lukas Bulwahn
2021-08-05 15:02   ` Davidlohr Bueso
2021-08-05 15:10     ` Peter Zijlstra
2021-08-05 17:20     ` Mete Polat
2021-08-06  8:52       ` Michel Lespinasse [this message]
2021-08-06 11:57         ` Peter Zijlstra
2021-08-10 22:46   ` Jesper Nilsson

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).