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?
* a node is an internal entry, do we need to compare with xa_mk_internal()
instead?
And also suggest to add a comment on this, otherwise it seems a little magic.
>> I found this in xarray.rst:
>>
>> Normal pointers may be stored in the XArray directly. They must be 4-byte
>> aligned, which is true for any pointer returned from kmalloc() and
>> alloc_page(). It isn't true for arbitrary user-space pointers,
>> nor for function pointers. You can store pointers to statically allocated
>> objects, as long as those objects have an alignment of at least 4.
>>
>> So the document here is not correct?
>
>Why do you say that?
>
>(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.
--
Wei Yang
Help you, Help me
