From: Julien Grall <julien.grall@arm.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>, xen-devel@lists.xen.org
Cc: sstabellini@kernel.org, wei.liu2@citrix.com,
George.Dunlap@eu.citrix.com, andrew.cooper3@citrix.com,
ian.jackson@eu.citrix.com, tim@xen.org, jbeulich@suse.com
Subject: Re: [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist
Date: Mon, 7 Aug 2017 16:23:54 +0100 [thread overview]
Message-ID: <c424867c-dfc0-1e24-b2ee-e5a675c2fcdf@arm.com> (raw)
In-Reply-To: <5a39b951-2604-b71f-1a6b-dc075a00ae26@oracle.com>
Hi,
On 07/08/17 15:46, Boris Ostrovsky wrote:
> On 08/07/2017 06:45 AM, Julien Grall wrote:
>> Hi Boris,
>>
>> I would have appreciated to be CCed as maintainer of the ARM bits...
>> Please use scripts/get_maintainers.pl in the future.
>
> Ugh, sorry about that. (I did test builds for both ARM64 and ARM32, if
> this make my transgression any less serious ;-))
>
>>
>> On 04/08/17 18:05, Boris Ostrovsky wrote:
>>> . so that it's easy to find pages that need to be scrubbed (those
>>> pages are
>>
>> Pointless .
>>
>>> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
>>> index ef84b72..d26b232 100644
>>> --- a/xen/include/asm-arm/mm.h
>>> +++ b/xen/include/asm-arm/mm.h
>>> @@ -44,7 +44,16 @@ struct page_info
>>> /* Page is on a free list: ((count_info & PGC_count_mask) ==
>>> 0). */
>>> struct {
>>> /* Do TLBs need flushing for safety before next page
>>> use? */
>>> - bool_t need_tlbflush;
>>> + unsigned long need_tlbflush:1;
>>
>> You've turned need_tlbflush from bool to unsigned long : 1. But some
>> of the users use true/false or may rely on the boolean property. So
>> it sounds like to me you want to use bool bitfields here (and in the
>> x86 part).
>
> This is what we have (with this series applied):
>
> root@ovs104> git grep need_tlbflush .
> common/memory.c: bool need_tlbflush = false;
> common/memory.c:
> accumulate_tlbflush(&need_tlbflush, &page[j],
> common/memory.c: if ( need_tlbflush )
> common/page_alloc.c: bool need_tlbflush = false;
> common/page_alloc.c: accumulate_tlbflush(&need_tlbflush, &pg[i],
> common/page_alloc.c: if ( need_tlbflush )
> * common/page_alloc.c: pg[i].u.free.need_tlbflush =
> (page_get_owner(&pg[i]) != NULL);
> common/page_alloc.c: if ( pg[i].u.free.need_tlbflush )
> include/asm-arm/mm.h: unsigned long need_tlbflush:1;
> include/asm-x86/mm.h: unsigned long need_tlbflush:1;
> include/xen/mm.h:static inline void accumulate_tlbflush(bool *need_tlbflush,
> include/xen/mm.h: if ( page->u.free.need_tlbflush &&
> include/xen/mm.h: (!*need_tlbflush ||
> include/xen/mm.h: *need_tlbflush = true;
> root@ovs104>
>
> The only possibly boolean-style use is '*' and event that I think is
> allowed.
>
> Stand-alone need_tlbflush variables above have nothing to do with this
> change.
If you look at it, all of them use bool semantic. Now you mix bool and
int. We are trying to remove that in the new code, so please don't
introduce new one.
>
>
>>
>>> +
>>> + /*
>>> + * Index of the first *possibly* unscrubbed page in the
>>> buddy.
>>> + * One more than maximum possible order to accommodate
>>> + * INVALID_DIRTY_IDX.
>>> + */
>>> +#define INVALID_DIRTY_IDX ((1UL << (MAX_ORDER + 1)) - 1)
>>> + unsigned long first_dirty:MAX_ORDER + 1;
>>
>> We need to make sure that this union will not be bigger than unsigned
>> long. Otherwise this will limit lower down the maximum amount of
>> memory we support.
>> So this likely means a BUILD_BUG_ON(....).
>
>
> Are you concerned that (MAX_ORDER+1) will be larger than sizeof(unsigned
> long)? If yes, the compiler should complain anyway, shouldn't it?
I am more concerned about the sizeof of the union u to be larger than
unsigned long.
first_dirty should not be greater than 63 bits (or 31 bits for 32-bits
architecture). Otherwise likely the compiler will add a padding between
need_tlbflush and first_dirty. This would increase the page_info by 4/8
byte.
The BUILD_BUG_ON(...) would be here to catch such error.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-08-07 15:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-04 17:05 [PATCH v6 0/8] Memory scrubbing from idle loop Boris Ostrovsky
2017-08-04 17:05 ` [PATCH v6 1/8] mm: Place unscrubbed pages at the end of pagelist Boris Ostrovsky
2017-08-06 17:41 ` Jan Beulich
2017-08-07 14:12 ` Boris Ostrovsky
2017-08-07 14:37 ` Jan Beulich
2017-08-07 14:55 ` Boris Ostrovsky
2017-08-07 15:28 ` Jan Beulich
2017-08-07 10:45 ` Julien Grall
2017-08-07 14:46 ` Boris Ostrovsky
2017-08-07 15:23 ` Julien Grall [this message]
2017-08-07 16:57 ` Boris Ostrovsky
2017-08-07 17:01 ` Julien Grall
2017-08-07 17:20 ` Boris Ostrovsky
2017-08-04 17:05 ` [PATCH v6 2/8] mm: Extract allocation loop from alloc_heap_pages() Boris Ostrovsky
2017-08-06 17:42 ` Jan Beulich
2017-08-04 17:05 ` [PATCH v6 3/8] mm: Scrub pages in alloc_heap_pages() if needed Boris Ostrovsky
2017-08-04 17:05 ` [PATCH v6 4/8] mm: Scrub memory from idle loop Boris Ostrovsky
2017-08-07 7:29 ` Jan Beulich
2017-08-07 14:05 ` Dario Faggioli
2017-08-04 17:05 ` [PATCH v6 5/8] spinlock: Introduce spin_lock_cb() Boris Ostrovsky
2017-08-07 7:32 ` Jan Beulich
2017-08-04 17:05 ` [PATCH v6 6/8] mm: Keep heap accessible to others while scrubbing Boris Ostrovsky
2017-08-07 7:50 ` Jan Beulich
2017-08-04 17:05 ` [PATCH v6 7/8] mm: Print number of unscrubbed pages in 'H' debug handler Boris Ostrovsky
2017-08-04 17:05 ` [PATCH v6 8/8] mm: Make sure pages are scrubbed Boris Ostrovsky
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=c424867c-dfc0-1e24-b2ee-e5a675c2fcdf@arm.com \
--to=julien.grall@arm.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=sstabellini@kernel.org \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.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 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).