xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 3/3] x86: introduce and use scratch CPU mask
Date: Thu, 15 Dec 2016 14:15:15 +0000	[thread overview]
Message-ID: <f7eba41f-a326-e99b-1e13-328f87ee9bb3@citrix.com> (raw)
In-Reply-To: <584A806F02000078001271FF@prv-mh.provo.novell.com>

On 09/12/16 08:59, Jan Beulich wrote:
>>>> On 08.12.16 at 18:51, <andrew.cooper3@citrix.com> wrote:
>> On 08/12/16 16:02, Jan Beulich wrote:
>>> variable. With an IRQ happening at the deepest point of the stack, and
>>> with send_guest_pirq() being called from there (leading to vcpu_kick()
>>> -> ... -> csched_vcpu_wake() -> __runq_tickle() ->
>>> cpumask_raise_softirq(), the last two of which also have CPU mask
>>> variables on their stacks), this has been observed to cause a stack
>> "stacks), has been".
> Hmm, that looks strange to me: Wouldn't the dropping of "this"
> also requite the "With" at the start of the sentence to be dropped
> (and isn't the sentence okay with both left in place)?

The use of "this" requires a substantial backtrack through the text to
evaluate what it refers to, which as you point, I didn't manage to do
successfully. 

As is evident, I had a very hard time trying to parse the sentence.

It would be clearer to read if you took out both the "With" and "this".

>
>>> @@ -2509,20 +2510,21 @@ static int __get_page_type(struct page_i
>>>                   * may be unnecessary (e.g., page was GDT/LDT) but those 
>>>                   * circumstances should be very rare.
>>>                   */
>>> -                cpumask_t mask;
>>> +                cpumask_t *mask = this_cpu(scratch_cpumask);
>> This indirection looks suspicious.  Why do you have a per_cpu pointer to
>> a cpumask, with a dynamically allocated mask?
>>
>> It would be smaller and more efficient overall to have a fully cpumask
>> allocated in the per-cpu area, and use it via
> Well, as you can see from the smpboot.c context of the
> modifications done, that's how other masks are being dealt with
> too. The reasoning is that it is quite wasteful to pre-allocate 512
> bytes for a CPU mask when on the running system perhaps only
> the low few bytes will be used.
>
> Overall I'm getting the impression from your comments that you
> simply didn't recognize the use of cpumask_t vs cpumask_var_t
> in the various places.

Ok - on the basis that this is the same as the prevailing uses,

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2016-12-15 14:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-08 15:54 [PATCH 0/3] misc cpumask adjustments Jan Beulich
2016-12-08 16:00 ` [PATCH 1/3] make tlbflush_filter()'s first parameter a pointer Jan Beulich
2016-12-08 16:26   ` Andrew Cooper
2016-12-09 10:39   ` Wei Liu
2016-12-09 18:05   ` Julien Grall
2016-12-08 16:01 ` [PATCH 2/3] VT-d: correct dma_msi_set_affinity() Jan Beulich
2016-12-08 17:33   ` Andrew Cooper
2016-12-09  8:47     ` Jan Beulich
2016-12-13  5:23       ` Tian, Kevin
2016-12-13  7:30         ` Jan Beulich
2016-12-14  4:58           ` Tian, Kevin
2016-12-15  9:54       ` Ping: " Jan Beulich
2016-12-15 12:52         ` Andrew Cooper
2016-12-15 14:16           ` Jan Beulich
2016-12-15 15:39             ` Andrew Cooper
2016-12-08 16:02 ` [PATCH 3/3] x86: introduce and use scratch CPU mask Jan Beulich
2016-12-08 17:51   ` Andrew Cooper
2016-12-09  8:59     ` Jan Beulich
2016-12-15  9:56       ` Ping: " Jan Beulich
2016-12-15 14:15       ` Andrew Cooper [this message]
2016-12-15 14:59         ` Jan Beulich
2016-12-15 15:38           ` Andrew Cooper

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=f7eba41f-a326-e99b-1e13-328f87ee9bb3@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --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 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).