From: Keir Fraser <keir.xen@gmail.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH 00/12] cpumask handling scalability improvements
Date: Fri, 21 Oct 2011 09:00:38 +0100 [thread overview]
Message-ID: <CAC6E536.23673%keir.xen@gmail.com> (raw)
In-Reply-To: <4EA13711020000780005CA36@nat28.tlf.novell.com>
On 21/10/2011 08:10, "Jan Beulich" <JBeulich@suse.com> wrote:
>> Aren't we planning to dynamically allocate irq_desc-s? That would seem the
>> nicer solution here.
>
> Yes, I would hope so. But irrespective of that, allocating e.g. 512 bits
> (times 4) just to use, say, 20-30 of them is bad - again, not so much
> from a memory wasting pov, but rather from the fact that this
> needlessly causes a larger cache and TLB footprint.
Oh, I don't mind you changing irq_desc to use cpumask_var_t-s. It's the
extra step of using an array to save a few pointers, that I reject.
> I actually think that ultimately we should try to remove all
> non-dynamically allocated CPU masks (including statics, per-CPU
> ones, and local variables - the latter being particularly important as
> they cause pretty big stack frames, despite there now being at
> most one [with the rare exception of two] of them per function,
> which will continue to grow with higher NR_CPUS values).
OTOH they are probably in some cases used in contexts where dynamic
allocation (and possibility of failure) is not nice? And we can compare this
effort with just increasing per-cpu stack sizes, for example?
I'm not particularly against moving in this direction, but there might be
cases where it isn't worth the effort, or there are better solutions.
-- Keir
next prev parent reply other threads:[~2011-10-21 8:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-20 13:36 [PATCH 00/12] cpumask handling scalability improvements Jan Beulich
2011-10-20 15:09 ` Keir Fraser
2011-10-20 15:19 ` Jan Beulich
2011-10-20 15:25 ` Jan Beulich
2011-10-20 15:49 ` Andrew Cooper
2011-10-20 15:57 ` Jan Beulich
2011-10-20 16:04 ` Keir Fraser
2011-10-21 7:10 ` Jan Beulich
2011-10-21 8:00 ` Keir Fraser [this message]
2011-10-21 8:23 ` Jan Beulich
2011-10-20 16:06 ` Keir Fraser
2011-10-21 7:01 ` Jan Beulich
2011-10-21 7:08 ` Keir Fraser
2011-10-21 7:14 ` Jan Beulich
2011-10-21 7:49 ` 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=CAC6E536.23673%keir.xen@gmail.com \
--to=keir.xen@gmail.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=xen-devel@lists.xensource.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.