From: Mike Travis <travis@sgi.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Paul Jackson <pj@sgi.com>,
tglx@linutronix.de, hpa@zytor.com, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] x86: add cpus_scnprintf function v2
Date: Mon, 07 Apr 2008 11:42:42 -0700 [thread overview]
Message-ID: <47FA6B22.9080900@sgi.com> (raw)
In-Reply-To: <20080407081643.GC3066@elte.hu>
Ingo Molnar wrote:
> * Paul Jackson <pj@sgi.com> wrote:
>
>> I still have some concerns with this cpus_scnprintf patch.
>>
>> I've taken them up with Mike offline for initial consideration.
>>
>> If others have questions, concerns or enthusiasms for this patch, Mike
>> and I would be interested.
>
> i dont mind the old patch either (which did an ugly temporary
> allocation), if it keeps the ABI. I dont think it's a big deal, lets not
> allow it to become a roadblock, and the overall goal of all these
> patches [4096 CPU support in upstream Linux] is important and i'm
> enthusiastic about that ;-)
>
> Ingo
I have no stake in the ground for this either. My assigned task was to
minimize the effect of bumping up the possible cpu count to a really
large amount. This seemed to me to fall in this category. A side goal
was to prepare for even larger cpu count systems.
An alternative that Paul had suggested was to introduce a new set of
file interfaces that produce the alternate format. This would not
break existing interfaces and allow a transition, though how many
post-processors of the information would change is unclear. Given
that fact, would the added code and complexity be worthwhile?
Thanks,
Mike
next prev parent reply other threads:[~2008-04-07 18:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-05 1:24 [PATCH 0/4] x86: add cpus_scnprintf function v2 Mike Travis
2008-04-05 1:24 ` [PATCH 1/4] " Mike Travis
2008-04-05 1:24 ` [PATCH 2/4] x86: modify show_shared_cpu_map in intel_cacheinfo v2 Mike Travis
2008-04-07 13:57 ` Bert Wesarg
2008-04-07 18:45 ` Mike Travis
2008-04-05 1:24 ` [PATCH 3/4] cpumask: use new cpus_scnprintf function v2 Mike Travis
2008-04-05 1:24 ` [PATCH 4/4] cpumask: add show cpu map functions Mike Travis
2008-04-07 8:04 ` [PATCH 0/4] x86: add cpus_scnprintf function v2 Paul Jackson
2008-04-07 8:16 ` Ingo Molnar
2008-04-07 8:44 ` Paul Jackson
2008-04-07 18:42 ` Mike Travis [this message]
2008-04-10 15:30 ` Paul Jackson
2008-04-07 14:07 ` Bert Wesarg
2008-04-07 18:22 ` Mike Travis
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=47FA6B22.9080900@sgi.com \
--to=travis@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pj@sgi.com \
--cc=tglx@linutronix.de \
/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.