From: Glauber Costa <glommer@parallels.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>,
Ingo Molnar <mingo@elte.hu>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>, <linux-next@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: linux-next: manual merge of the tip tree with the cputime tree
Date: Tue, 20 Dec 2011 14:19:54 +0400 [thread overview]
Message-ID: <4EF0614A.9020402@parallels.com> (raw)
In-Reply-To: <1324303723.24621.1.camel@twins>
On 12/19/2011 06:08 PM, Peter Zijlstra wrote:
> On Mon, 2011-12-19 at 13:31 +0100, Martin Schwidefsky wrote:
>> Just one question: are you sure that you want the cpustat array
>> to be u64 instead of cputime64_t? The content of the cpustat array is defined
>> by the architecture semantics of cputime64_t, for CONFIG_VIRT_CPU_ACCOUNTING=y
>> this is not a jiffy counter. If the array is u64 we won't get the sparse
>> checking when reading from cpustat.
>
> So as Glauber said the reason was that we wanted to use simply
> operators, and IIRC he wanted to add a few fields that had to be u64.
>
> I'm not sure what the current plans are wrt adding more fields, but with
> your work cputime_t should again be a simple type and thus regular math
> operators should work again, right?
>
> Glauber, do you still need to add fields?
Due to the current state of discussions of cpu vs cpuacct, I think the
final state of this is quite unclear. However, I think Martin's work is
a quite worthwhile piece for us to have. So last case we can add extra
fields in a different array and tell them apart by the index, etc. It
shouldn't be expensive at all.
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer@parallels.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>,
Ingo Molnar <mingo@elte.hu>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: linux-next: manual merge of the tip tree with the cputime tree
Date: Tue, 20 Dec 2011 14:19:54 +0400 [thread overview]
Message-ID: <4EF0614A.9020402@parallels.com> (raw)
In-Reply-To: <1324303723.24621.1.camel@twins>
On 12/19/2011 06:08 PM, Peter Zijlstra wrote:
> On Mon, 2011-12-19 at 13:31 +0100, Martin Schwidefsky wrote:
>> Just one question: are you sure that you want the cpustat array
>> to be u64 instead of cputime64_t? The content of the cpustat array is defined
>> by the architecture semantics of cputime64_t, for CONFIG_VIRT_CPU_ACCOUNTING=y
>> this is not a jiffy counter. If the array is u64 we won't get the sparse
>> checking when reading from cpustat.
>
> So as Glauber said the reason was that we wanted to use simply
> operators, and IIRC he wanted to add a few fields that had to be u64.
>
> I'm not sure what the current plans are wrt adding more fields, but with
> your work cputime_t should again be a simple type and thus regular math
> operators should work again, right?
>
> Glauber, do you still need to add fields?
Due to the current state of discussions of cpu vs cpuacct, I think the
final state of this is quite unclear. However, I think Martin's work is
a quite worthwhile piece for us to have. So last case we can add extra
fields in a different array and tell them apart by the index, etc. It
shouldn't be expensive at all.
next prev parent reply other threads:[~2011-12-20 10:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-19 4:40 linux-next: manual merge of the tip tree with the cputime tree Stephen Rothwell
2011-12-19 8:08 ` Ingo Molnar
2011-12-19 9:11 ` Martin Schwidefsky
2011-12-19 10:35 ` Ingo Molnar
2011-12-19 11:25 ` Ingo Molnar
2011-12-19 14:24 ` Martin Schwidefsky
2011-12-19 16:30 ` Ingo Molnar
2011-12-19 19:06 ` Martin Schwidefsky
2011-12-20 11:09 ` Ingo Molnar
2011-12-19 12:31 ` Martin Schwidefsky
2011-12-19 13:43 ` Glauber Costa
2011-12-19 13:43 ` Glauber Costa
2011-12-19 14:19 ` Martin Schwidefsky
2011-12-19 14:19 ` Martin Schwidefsky
2011-12-19 14:08 ` Peter Zijlstra
2011-12-19 14:25 ` Martin Schwidefsky
2011-12-20 10:19 ` Glauber Costa [this message]
2011-12-20 10:19 ` Glauber Costa
-- strict thread matches above, loose matches on Subject: below --
2011-12-07 4:09 Stephen Rothwell
2011-12-07 11:35 ` Glauber Costa
2011-12-07 11:35 ` Glauber Costa
2011-12-07 11:59 ` Martin Schwidefsky
2011-12-07 11:59 ` Martin Schwidefsky
2011-10-25 7:44 Stephen Rothwell
2011-10-25 7:40 Stephen Rothwell
2011-10-25 15:29 ` Michal Hocko
2011-10-25 7:35 Stephen Rothwell
2011-10-25 15:28 ` Michal Hocko
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=4EF0614A.9020402@parallels.com \
--to=glommer@parallels.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=schwidefsky@de.ibm.com \
--cc=sfr@canb.auug.org.au \
--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.