All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Wei Yang <richard.weiyang@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/9] XArray: internal node is a xa_node when it is bigger than XA_ZERO_ENTRY
Date: Mon, 30 Mar 2020 17:06:49 -0700	[thread overview]
Message-ID: <20200331000649.GG22483@bombadil.infradead.org> (raw)
In-Reply-To: <20200330222013.34nkqen2agujhd6j@master>

On Mon, Mar 30, 2020 at 10:20:13PM +0000, Wei Yang wrote:
> On Mon, Mar 30, 2020 at 07:27:08AM -0700, Matthew Wilcox wrote:
> >On Mon, Mar 30, 2020 at 02:13:50PM +0000, Wei Yang wrote:
> >> On Mon, Mar 30, 2020 at 06:49:03AM -0700, Matthew Wilcox wrote:
> >> >On Mon, Mar 30, 2020 at 01:45:19PM +0000, Wei Yang wrote:
> >> >> On Mon, Mar 30, 2020 at 05:50:06AM -0700, Matthew Wilcox wrote:
> >> >> >On Mon, Mar 30, 2020 at 12:36:40PM +0000, Wei Yang wrote:
> >> >> >> As the comment mentioned, we reserved several ranges of internal node
> >> >> >> for tree maintenance, 0-62, 256, 257. This means a node bigger than
> >> >> >> XA_ZERO_ENTRY is a normal node.
> >> >> >> 
> >> >> >> The checked on XA_ZERO_ENTRY seems to be more meaningful.
> >> >> >
> >> >> >257-1023 are also reserved, they just aren't used yet.  XA_ZERO_ENTRY
> >> >> >is not guaranteed to be the largest reserved entry.
> >> >> 
> >> >> Then why we choose 4096?
> >> >
> >> >Because 4096 is the smallest page size supported by Linux, so we're
> >> >guaranteed that anything less than 4096 is not a valid pointer.
> >> 
> 
> So you want to say, the 4096 makes sure XArray will not store an address in
> first page? If this is the case, I have two suggestions:
> 
>   * use PAGE_SIZE would be more verbose?

But also incorrect, because it'll be different on different architectures.
It's 4096.  That's all.

>   * a node is an internal entry, do we need to compare with xa_mk_internal()
>     instead?

No.  4096 is better because it's a number which is easily expressible in
many CPU instruction sets.  4094 is much less likely to be an easy number
to encode.

> >(it is slightly out of date; the XArray actually supports storing unaligned
> >pointers now, but that's not relevant to this discussion)
> 
> Ok, maybe this document need to update.

Did you want to send a patch?

  reply	other threads:[~2020-03-31  0:06 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30 12:36 [PATCH 0/9] XArray: several cleanups Wei Yang
2020-03-30 12:36 ` [PATCH 1/9] XArray: fix comment on Zero/Retry entry Wei Yang
2020-03-30 12:46   ` Matthew Wilcox
2020-03-30 13:42     ` Wei Yang
2020-03-30 12:36 ` [PATCH 2/9] XArray: simplify the calculation of shift Wei Yang
2020-03-30 13:20   ` Matthew Wilcox
2020-03-30 14:07     ` Wei Yang
2020-03-30 12:36 ` [PATCH 3/9] XArray: handle a NULL head by itself Wei Yang
2020-03-30 12:36 ` [PATCH 4/9] XArray: don't expect to have more nr_values than count Wei Yang
2020-03-30 12:36 ` [PATCH 5/9] XArray: entry in last level is not expected to be a node Wei Yang
2020-03-30 12:48   ` Matthew Wilcox
2020-03-30 14:15     ` Wei Yang
2020-03-30 14:28       ` Matthew Wilcox
2020-03-30 22:10         ` Wei Yang
2020-03-31 13:42         ` Wei Yang
2020-03-31 16:42           ` Matthew Wilcox
2020-03-31 22:04             ` Wei Yang
2020-03-31 23:59               ` Matthew Wilcox
2020-04-01 22:10                 ` Wei Yang
2020-04-01 22:20                   ` Matthew Wilcox
2020-04-02 12:36                     ` Wei Yang
2020-04-03 22:39                     ` Wei Yang
2020-04-04 15:37                       ` Matthew Wilcox
2020-04-05 11:07                     ` Wei Yang
2020-04-05 21:56                       ` Matthew Wilcox
2020-04-06  1:14                         ` Wei Yang
2020-04-06  1:24     ` Wei Yang
2020-04-11 13:56       ` Wei Yang
2020-04-28 21:24     ` Wei Yang
2020-03-30 12:36 ` [PATCH 6/9] XArray: internal node is a xa_node when it is bigger than XA_ZERO_ENTRY Wei Yang
2020-03-30 12:50   ` Matthew Wilcox
2020-03-30 13:45     ` Wei Yang
2020-03-30 13:49       ` Matthew Wilcox
2020-03-30 14:13         ` Wei Yang
2020-03-30 14:27           ` Matthew Wilcox
2020-03-30 22:20             ` Wei Yang
2020-03-31  0:06               ` Matthew Wilcox [this message]
2020-03-31 13:40                 ` Wei Yang
2020-03-30 12:36 ` [PATCH 7/9] XArray: the NULL xa_node condition is handled in xas_top Wei Yang
2020-03-30 12:36 ` [PATCH 8/9] XArray: take xas_error() handling for clearer logic Wei Yang
2020-03-30 12:36 ` [PATCH 9/9] XArray: adjust xa_offset till it gets the correct node Wei Yang

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=20200331000649.GG22483@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard.weiyang@gmail.com \
    /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.