All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien@xen.org>
To: Jan Beulich <jbeulich@suse.com>,
	Carlo Nonato <carlo.nonato@minervasys.tech>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags macro
Date: Wed, 27 Mar 2024 13:48:32 +0000	[thread overview]
Message-ID: <cdee3c70-c1cc-4787-8d75-ac00c95463b7@xen.org> (raw)
In-Reply-To: <fe433260-c8c9-419d-8b05-50e2cc50d127@suse.com>



On 27/03/2024 13:38, Jan Beulich wrote:
> On 27.03.2024 14:28, Julien Grall wrote:
>> Hi Carlo,
>>
>> On 27/03/2024 11:10, Carlo Nonato wrote:
>>> Hi guys,
>>>
>>>> Question is: How would you justify such a change? IOW I'm not convinced
>>>> (yet) this wants doing there.
>>>
>>> You mean in this series?
>>>
>>>> Looking at the code, the flag is originally set in
>>>> alloc_domheap_pages(). So I guess it would make sense to do it in
>>>> free_domheap_pages().
>>>
>>> We don't hold the heap_lock there.
>> Regardless of the safety question (I will answer below), count_info is
>> not meant to be protected by heap_lock. The lock is protecting the heap
>> and ensure we are not corrupting them when there are concurrent call to
>> free_heap_pages().
>>
>>   > Is it safe to change count_info without it?
>>
>> count_info is meant to be accessed locklessly. The flag PGC_extra cannot
>> be set/clear concurrently because you can't allocate a page that has not
>> yet been freed.
>>
>> So it would be fine to use clear_bit(..., ...);
> 
> Actually we hardly ever use clear_bit() on count_info. Normally we use
> ordinary C operators.

I knew you would say that. I am not convince it is safe to always using 
count_info without any atomic operations. But I never got around to 
check all them.

> Atomic (and otherwise lockless) updates are useful
> only if done like this everywhere.

You are right. But starting to use the bitops is not going to hurt 
anyone (other than maybe performance, but once we convert all of them, 
then this will become moot). In fact, it helps start to slowly move 
towards the aim to have count_info safe.

Cheers,

-- 
Julien Grall


  reply	other threads:[~2024-03-27 13:48 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-15 10:58 [PATCH v7 00/14] Arm cache coloring Carlo Nonato
2024-03-15 10:58 ` [PATCH v7 01/14] xen/common: add cache coloring common code Carlo Nonato
2024-03-15 11:39   ` Carlo Nonato
2024-03-19 14:58   ` Jan Beulich
2024-03-21 15:03     ` Carlo Nonato
2024-03-21 15:53       ` Jan Beulich
2024-03-21 17:22         ` Carlo Nonato
2024-03-22  7:25           ` Jan Beulich
2024-03-15 10:58 ` [PATCH v7 02/14] xen/arm: add initial support for LLC coloring on arm64 Carlo Nonato
2024-03-15 10:58 ` [PATCH v7 03/14] xen/arm: permit non direct-mapped Dom0 construction Carlo Nonato
2024-03-15 10:58 ` [PATCH v7 04/14] xen/arm: add Dom0 cache coloring support Carlo Nonato
2024-03-19 15:30   ` Jan Beulich
2024-03-21 15:04     ` Carlo Nonato
2024-03-21 15:57       ` Jan Beulich
2024-03-21 17:31         ` Carlo Nonato
2024-03-22  7:26           ` Jan Beulich
2024-03-27 11:39             ` Carlo Nonato
2024-03-27 11:56               ` Julien Grall
2024-04-05  0:20                 ` Stefano Stabellini
2024-03-27 11:57               ` Michal Orzel
2024-03-19 15:45   ` Jan Beulich
2024-03-15 10:58 ` [PATCH v7 05/14] xen: extend domctl interface for cache coloring Carlo Nonato
2024-03-19 15:37   ` Jan Beulich
2024-03-21 15:11     ` Carlo Nonato
2024-03-15 10:58 ` [PATCH v7 06/14] tools: add support for cache coloring configuration Carlo Nonato
2024-03-25 10:55   ` Anthony PERARD
2024-03-25 11:44     ` Carlo Nonato
2024-03-15 10:58 ` [PATCH v7 07/14] xen/arm: add support for cache coloring configuration via device-tree Carlo Nonato
2024-03-19 15:41   ` Jan Beulich
2024-03-21 15:12     ` Carlo Nonato
2024-03-15 10:58 ` [PATCH v7 08/14] xen/page_alloc: introduce preserved page flags macro Carlo Nonato
2024-03-19 15:47   ` Jan Beulich
2024-03-21 16:07   ` Julien Grall
2024-03-21 16:10     ` Julien Grall
2024-03-21 16:22       ` Jan Beulich
2024-03-22 15:07         ` Carlo Nonato
2024-03-25  7:19           ` Jan Beulich
2024-03-26 16:39             ` Carlo Nonato
2024-03-26 17:04               ` Jan Beulich
2024-03-26 21:55                 ` Julien Grall
2024-03-27 11:10                   ` Carlo Nonato
2024-03-27 13:28                     ` Julien Grall
2024-03-27 13:38                       ` Jan Beulich
2024-03-27 13:48                         ` Julien Grall [this message]
2024-03-28 18:21                           ` Julien Grall
2024-03-15 10:58 ` [PATCH v7 09/14] xen/page_alloc: introduce page flag to stop buddy merging Carlo Nonato
2024-03-19 15:49   ` Jan Beulich
2024-03-15 10:58 ` [PATCH v7 10/14] xen: add cache coloring allocator for domains Carlo Nonato
2024-03-19 16:43   ` Jan Beulich
2024-03-21 15:36     ` Carlo Nonato
2024-03-21 16:03       ` Jan Beulich
2024-03-15 10:58 ` [PATCH v7 11/14] xen/arm: use domain memory to allocate p2m page tables Carlo Nonato
2024-03-15 10:59 ` [PATCH v7 12/14] xen/arm: add Xen cache colors command line parameter Carlo Nonato
2024-03-19 15:54   ` Jan Beulich
2024-03-21 15:36     ` Carlo Nonato
2024-03-15 10:59 ` [PATCH v7 13/14] xen/arm: make consider_modules() available for xen relocation Carlo Nonato
2024-03-15 10:59 ` [PATCH v7 14/14] xen/arm: add cache coloring support for Xen Carlo Nonato
2024-03-19 15:58   ` Jan Beulich
2024-03-19 16:15     ` Jan Beulich
2024-03-19 16:03   ` Jan Beulich

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=cdee3c70-c1cc-4787-8d75-ac00c95463b7@xen.org \
    --to=julien@xen.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=carlo.nonato@minervasys.tech \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.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.