On 12/11/2012 7:48 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
Another testing of parallel compress with pigz on Linus' git tree.
results show we get much better performance/power with powersaving and
balance policy:
testing command:
#pigz -k -c -p$x
On 12/11/2012 8:13 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:03:01AM -0800, Arjan van de Ven wrote:
On 12/11/2012 7:48 AM, Borislav Petkov wrote:
On Tue, Dec 11, 2012 at 08:10:20PM +0800, Alex Shi wrote:
Another testing of parallel compress with pigz on Linus' git tree.
results
On 11/13/2012 5:34 PM, Paul E. McKenney wrote:
> On Tue, Nov 13, 2012 at 05:14:50PM -0800, Jacob Pan wrote:
>> On Tue, 13 Nov 2012 16:08:54 -0800
>> Arjan van de Ven wrote:
>>
>>>> I think I know, but I feel the need to ask anyway. Why not tell
>>>> R
>
> OK, so the point of clamping all sockets simultaneously is to be able
> to power down the electronics surrounding the sockets as well as the
> sockets themselves?
yup; memory can go to self refresh etc etc
>If all you cared about was the individual sockets,
> I don't see why you couldn't
On 11/13/2012 2:23 PM, Paul E. McKenney wrote:
> On Tue, Nov 13, 2012 at 01:39:22PM -0800, Jacob Pan wrote:
>> On Tue, 13 Nov 2012 13:16:02 -0800
>> "Paul E. McKenney" wrote:
>>
Please refer to Documentation/thermal/intel_powerclamp.txt for more
details.
>>>
>>> If I read this
On 11/13/2012 1:16 PM, Paul E. McKenney wrote:
> On Mon, Nov 12, 2012 at 02:03:51PM -0800, Jacob Pan wrote:
>> Intel PowerClamp driver performs synchronized idle injection across
>> all online CPUs. The goal is to maintain a given package level C-state
>> ratio.
>>
>> Compared to other throttling
On 11/13/2012 1:16 PM, Paul E. McKenney wrote:
On Mon, Nov 12, 2012 at 02:03:51PM -0800, Jacob Pan wrote:
Intel PowerClamp driver performs synchronized idle injection across
all online CPUs. The goal is to maintain a given package level C-state
ratio.
Compared to other throttling methods
On 11/13/2012 2:23 PM, Paul E. McKenney wrote:
On Tue, Nov 13, 2012 at 01:39:22PM -0800, Jacob Pan wrote:
On Tue, 13 Nov 2012 13:16:02 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
Please refer to Documentation/thermal/intel_powerclamp.txt for more
details.
If I read this
OK, so the point of clamping all sockets simultaneously is to be able
to power down the electronics surrounding the sockets as well as the
sockets themselves?
yup; memory can go to self refresh etc etc
If all you cared about was the individual sockets,
I don't see why you couldn't power
On 11/13/2012 5:34 PM, Paul E. McKenney wrote:
On Tue, Nov 13, 2012 at 05:14:50PM -0800, Jacob Pan wrote:
On Tue, 13 Nov 2012 16:08:54 -0800
Arjan van de Ven ar...@linux.intel.com wrote:
I think I know, but I feel the need to ask anyway. Why not tell
RCU about the clamping?
I don't mind
On 11/8/2012 9:14 PM, Vaidyanathan Srinivasan wrote:
> * Mel Gorman [2012-11-08 18:02:57]:
>
>> On Wed, Nov 07, 2012 at 01:22:13AM +0530, Srivatsa S. Bhat wrote:
>>>
>
> Hi Mel,
>
> Thanks for detailed review and comments. The goal
On 11/8/2012 9:14 PM, Vaidyanathan Srinivasan wrote:
* Mel Gorman mgor...@suse.de [2012-11-08 18:02:57]:
On Wed, Nov 07, 2012 at 01:22:13AM +0530, Srivatsa S. Bhat wrote:
Hi Mel,
Thanks for detailed review and comments. The
> Please let me know what you think :)
>
btw on what kind of hardware are you seeing the issues ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 8/23/2012 2:11 PM, Rik van Riel wrote:
> This patch set is mostly there to kick off a discussion in time
> for Kernel Summit. When running it on my laptop, with acpi_idle,
> I see a promising change in powertop.
be careful with acpi_idle... that will remove most of the intermediate C states
On 8/23/2012 2:11 PM, Rik van Riel wrote:
This patch set is mostly there to kick off a discussion in time
for Kernel Summit. When running it on my laptop, with acpi_idle,
I see a promising change in powertop.
be careful with acpi_idle... that will remove most of the intermediate C states
the
Please let me know what you think :)
btw on what kind of hardware are you seeing the issues ?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 8/22/2012 6:21 AM, Matthew Garrett wrote:
> On Wed, Aug 22, 2012 at 06:02:48AM -0700, Arjan van de Ven wrote:
>> On 8/21/2012 10:41 PM, Mike Galbraith wrote:
>>> For my dinky dual core laptop, I suspect you're right, but for a more
>>> powerful laptop, I'd expect sp
On 8/21/2012 10:41 PM, Mike Galbraith wrote:
> On Tue, 2012-08-21 at 17:02 +0100, Alan Cox wrote:
>
>> I'd like to see actual numbers and evidence on a wide range of workloads
>> the spread/don't spread thing is even measurable given that you've also
>> got to factor in effects like completing
On 8/21/2012 10:41 PM, Mike Galbraith wrote:
On Tue, 2012-08-21 at 17:02 +0100, Alan Cox wrote:
I'd like to see actual numbers and evidence on a wide range of workloads
the spread/don't spread thing is even measurable given that you've also
got to factor in effects like completing faster and
On 8/22/2012 6:21 AM, Matthew Garrett wrote:
On Wed, Aug 22, 2012 at 06:02:48AM -0700, Arjan van de Ven wrote:
On 8/21/2012 10:41 PM, Mike Galbraith wrote:
For my dinky dual core laptop, I suspect you're right, but for a more
powerful laptop, I'd expect spread/don't to be noticeable.
yeah
>>> A modern kernel better know what state the system is in: on
>>> battery or on AC power.
>>
>> That's a fundamentally uninteresting thing for the kernel to
>> know about. [...]
>
> I disagree.
and I'll agree with Matthew and disagree with you ;-)
>
>> [...] AC/battery is just not an
A modern kernel better know what state the system is in: on
battery or on AC power.
That's a fundamentally uninteresting thing for the kernel to
know about. [...]
I disagree.
and I'll agree with Matthew and disagree with you ;-)
[...] AC/battery is just not an important power
On 8/20/2012 1:06 AM, Ingo Molnar wrote:
>
>
> There's also cases where the kernel has insufficient information
> from the hardware and from the admin about the preferred
> characteristics/policy of the system - a tweakable fallback knob
> might be provided for that sad case.
>
> The point
On 8/20/2012 1:06 AM, Ingo Molnar wrote:
There's also cases where the kernel has insufficient information
from the hardware and from the admin about the preferred
characteristics/policy of the system - a tweakable fallback knob
might be provided for that sad case.
The point is, that
On 8/18/2012 7:33 AM, Luming Yu wrote:
> saving mode. But obviously, we need to spread as much as possible
> across all cores in another socket(to race to idle). So from the
> example above, we see a threshold that we need to reference before
> selecting one from two complete different policy:
On 8/18/2012 7:33 AM, Luming Yu wrote:
saving mode. But obviously, we need to spread as much as possible
across all cores in another socket(to race to idle). So from the
example above, we see a threshold that we need to reference before
selecting one from two complete different policy: spread
On 8/17/2012 11:41 AM, Matthew Garrett wrote:
> On Thu, Aug 16, 2012 at 07:01:25AM -0700, Arjan van de Ven wrote:
>>> *Power policy*:
>>>
>>> So how is power policy different? As Peter says,'pack more than spread
>>> more'.
>>
>> this is ...
On 8/17/2012 11:41 AM, Matthew Garrett wrote:
On Thu, Aug 16, 2012 at 07:01:25AM -0700, Arjan van de Ven wrote:
*Power policy*:
So how is power policy different? As Peter says,'pack more than spread
more'.
this is ... a dubiously general statement.
for good power, at least on Intel cpus
On 8/16/2012 11:45 AM, Rik van Riel wrote:
>
> The c-state governor can call the scheduler code before
> putting a CPU to sleep, to indicate (1) the wakeup latency
> of the CPU, and (2) whether TLB and/or cache get invalidated.
I don't think (2) is useful really; that basically always happens
> *Power policy*:
>
> So how is power policy different? As Peter says,'pack more than spread
> more'.
this is ... a dubiously general statement.
for good power, at least on Intel cpus, you want to spread. Parallelism is
efficient.
the only thing you do not want to do, is wake cpus up for
On 8/15/2012 10:03 PM, Alex Shi wrote:
> On 08/16/2012 12:19 AM, Matthew Garrett wrote:
>
>> On Mon, Aug 13, 2012 at 08:21:00PM +0800, Alex Shi wrote:
>>
>>> power aware scheduling), this proposal will adopt the
>>> sched_balance_policy concept and use 2 kind of policy: performance, power.
>>
>>
On 8/15/2012 10:03 PM, Alex Shi wrote:
On 08/16/2012 12:19 AM, Matthew Garrett wrote:
On Mon, Aug 13, 2012 at 08:21:00PM +0800, Alex Shi wrote:
power aware scheduling), this proposal will adopt the
sched_balance_policy concept and use 2 kind of policy: performance, power.
Are there
*Power policy*:
So how is power policy different? As Peter says,'pack more than spread
more'.
this is ... a dubiously general statement.
for good power, at least on Intel cpus, you want to spread. Parallelism is
efficient.
the only thing you do not want to do, is wake cpus up for
tasks
On 8/16/2012 11:45 AM, Rik van Riel wrote:
The c-state governor can call the scheduler code before
putting a CPU to sleep, to indicate (1) the wakeup latency
of the CPU, and (2) whether TLB and/or cache get invalidated.
I don't think (2) is useful really; that basically always happens ;-)
On 8/15/2012 6:14 PM, Rik van Riel wrote:
>
> The idea Matthew and I have is simply planning for a shorter
> sleep period (discarding the outliers to the high end in the
> function once known as detect_repeating_patterns), and going
> to a deeper C state if we have significantly overslept.
>
>
On 8/15/2012 6:14 PM, Rik van Riel wrote:
> On 08/15/2012 10:43 AM, Arjan van de Ven wrote:
>
>> The easy cop-out is provide the sysadmin a slider.
>> The slightly less easy one is to (and we're taking this approach
>> in the new P state code we're working on) say &q
On 8/15/2012 9:34 AM, Matthew Garrett wrote:
> On Wed, Aug 15, 2012 at 01:05:38PM +0200, Peter Zijlstra wrote:
>> On Mon, 2012-08-13 at 20:21 +0800, Alex Shi wrote:
>>> It bases on the following assumption:
>>> 1, If there are many task crowd in system, just let few domain cpus
>>> running and let
On 8/15/2012 8:04 AM, Peter Zijlstra wrote:
> This all sounds far too complicated.. we're talking about simple
> spreading and packing balancers without deep arch knowledge and knobs,
> we couldn't possibly evaluate anything like that.
>
> I was really more thinking of something useful for the
On 8/15/2012 7:39 AM, Peter Zijlstra wrote:
> On Wed, 2012-08-15 at 06:45 -0700, Arjan van de Ven wrote:
>> On 8/15/2012 4:05 AM, Peter Zijlstra wrote:
>>> Yay, ideally we'd also provide a 3rd option: auto, which simply switches
>>> between the two based on
On 8/15/2012 4:05 AM, Peter Zijlstra wrote:
> I'm not sure this is a valid assumption. I've had it explained to me by
> various people that race-to-idle isn't always the best thing.
it's not so much race to idle (which is more about frequency than anything else)
it's about the situation that in
On 8/15/2012 4:05 AM, Peter Zijlstra wrote:
> Yay, ideally we'd also provide a 3rd option: auto, which simply switches
> between the two based on AC/BAT, UPS
nooo!
anything but this.
if anyone thinks that AC/Battery matters for power sensitivity... they need to
go talk to a datacenter
On 8/15/2012 4:05 AM, Peter Zijlstra wrote:
Yay, ideally we'd also provide a 3rd option: auto, which simply switches
between the two based on AC/BAT, UPS
nooo!
anything but this.
if anyone thinks that AC/Battery matters for power sensitivity... they need to
go talk to a datacenter
On 8/15/2012 4:05 AM, Peter Zijlstra wrote:
I'm not sure this is a valid assumption. I've had it explained to me by
various people that race-to-idle isn't always the best thing.
it's not so much race to idle (which is more about frequency than anything else)
it's about the situation that in
On 8/15/2012 7:39 AM, Peter Zijlstra wrote:
On Wed, 2012-08-15 at 06:45 -0700, Arjan van de Ven wrote:
On 8/15/2012 4:05 AM, Peter Zijlstra wrote:
Yay, ideally we'd also provide a 3rd option: auto, which simply switches
between the two based on AC/BAT, UPS
nooo!
anything
On 8/15/2012 8:04 AM, Peter Zijlstra wrote:
This all sounds far too complicated.. we're talking about simple
spreading and packing balancers without deep arch knowledge and knobs,
we couldn't possibly evaluate anything like that.
I was really more thinking of something useful for the laptops
On 8/15/2012 9:34 AM, Matthew Garrett wrote:
On Wed, Aug 15, 2012 at 01:05:38PM +0200, Peter Zijlstra wrote:
On Mon, 2012-08-13 at 20:21 +0800, Alex Shi wrote:
It bases on the following assumption:
1, If there are many task crowd in system, just let few domain cpus
running and let other cpus
On 8/15/2012 6:14 PM, Rik van Riel wrote:
On 08/15/2012 10:43 AM, Arjan van de Ven wrote:
The easy cop-out is provide the sysadmin a slider.
The slightly less easy one is to (and we're taking this approach
in the new P state code we're working on) say in the default
setting, we're going
On 8/15/2012 6:14 PM, Rik van Riel wrote:
The idea Matthew and I have is simply planning for a shorter
sleep period (discarding the outliers to the high end in the
function once known as detect_repeating_patterns), and going
to a deeper C state if we have significantly overslept.
The new
On 7/9/2012 12:56 AM, Jean Delvare wrote:
> Back to my initial question, am I right to assume that
> CONFIG_CC_STACKPROTECTOR is no longer experimental and can be enabled in
> distribution kernels?
it HAS been enabled in distribution kernels for YEARS.
so yes.
--
To unsubscribe from this list:
On 7/9/2012 12:56 AM, Jean Delvare wrote:
Back to my initial question, am I right to assume that
CONFIG_CC_STACKPROTECTOR is no longer experimental and can be enabled in
distribution kernels?
it HAS been enabled in distribution kernels for YEARS.
so yes.
--
To unsubscribe from this list:
;> no longer considered experimental.
>>>
>>> Signed-off-by: Jean Delvare
>>> Cc: Ingo Molnar
>>> Cc: Arjan van de Ven
>>> Cc: Andi Kleen
>>> ---
>>> Or is there any reason to still consider this an experimental feature?
>>
>&g
Delvare jdelv...@suse.de
Cc: Ingo Molnar mi...@redhat.com
Cc: Arjan van de Ven ar...@linux.intel.com
Cc: Andi Kleen a...@firstfloor.org
---
Or is there any reason to still consider this an experimental feature?
I doubt it, but if it is still experimental, it should also have
depends
Gabriel C wrote:
Arjan van de Ven wrote:
Gabriel C wrote:
Laurent Riffard wrote:
Le 16.02.2008 09:25, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
[..]
I'm getting that in mainline now on one of my older laptops also.
we
Gabriel C wrote:
Arjan van de Ven wrote:
Gabriel C wrote:
Laurent Riffard wrote:
Le 16.02.2008 09:25, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
[..]
I'm getting that in mainline now on one of my older laptops also.
we
Gabriel C wrote:
Laurent Riffard wrote:
Le 16.02.2008 09:25, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
[..]
I'm getting that in mainline now on one of my older laptops also.
we fixed the cause of the machine you
Gabriel C wrote:
Laurent Riffard wrote:
Le 16.02.2008 09:25, Andrew Morton a écrit :
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc2/2.6.25-rc2-mm1/
[..]
I'm getting that in mainline now on one of my older laptops also.
we fixed the cause of the machine you
PROTECTED]>
>
> commit: e06b8b98da071f7dd78fb7822991694288047df0
>
> Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> ===
> I just read the excellent LWN writeup of the vmsplice
> security thing, and that got me wondering why this attack
> wasn't stopped by the CONFIG_C
return;
> @@ -37,6 +39,8 @@ static void
> save_stack_address_nosched(void *data, unsigned long addr, int
> reliable) {
> struct stack_trace *trace = (struct stack_trace *)data;
> + if (!reliable)
> + return;
> if (in_sched_functions(addr))
>
On Fri, 22 Feb 2008 07:43:08 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, 22 Feb 2008, Sam Ravnborg wrote:
> >
> > This is a regression. Can you please revert this commit.
>
> Not really. The thing is, CONFIG_CC_STACKPROTECTOR has never done
> anything at all, now it
On Fri, 22 Feb 2008 07:43:08 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
On Fri, 22 Feb 2008, Sam Ravnborg wrote:
This is a regression. Can you please revert this commit.
Not really. The thing is, CONFIG_CC_STACKPROTECTOR has never done
anything at all, now it does, and it
)
+ return;
if (in_sched_functions(addr))
return;
if (trace-skip 0) {
I was about to make a patch for this second chunk myself and submit it, so
for the second chunk a strong:
Acked-by: Arjan van de Ven [EMAIL PROTECTED]
Thanks for beating me to it ;-)
--
If you
: e06b8b98da071f7dd78fb7822991694288047df0
Arjan van de Ven [EMAIL PROTECTED] wrote:
===
I just read the excellent LWN writeup of the vmsplice
security thing, and that got me wondering why this attack
wasn't stopped by the CONFIG_CC_STACKPROTECTOR option...
because it plain should have been...
Some
On Fri, 22 Feb 2008 11:29:37 +1100 (EST)
James Morris <[EMAIL PROTECTED]> wrote:
> I've been getting an immediate hang on boot since:
>
> e06b8b98da071f7dd78fb7822991694288047df0 kbuild: allow
> -fstack-protector to take effect
>
> This is on an x86_64 system (actually an Intel SDV -- so it
Here are some PCI patches against your 2.6.25-rc2 git tree.
They are a collection of PCI quirk additions, build fixes, and some PCI
hotplug fixes.
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6.git/
The full patches will be sent to the linux-pci mailing
Here are some PCI patches against your 2.6.25-rc2 git tree.
They are a collection of PCI quirk additions, build fixes, and some PCI
hotplug fixes.
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6.git/
The full patches will be sent to the linux-pci mailing
On Fri, 22 Feb 2008 11:29:37 +1100 (EST)
James Morris [EMAIL PROTECTED] wrote:
I've been getting an immediate hang on boot since:
e06b8b98da071f7dd78fb7822991694288047df0 kbuild: allow
-fstack-protector to take effect
This is on an x86_64 system (actually an Intel SDV -- so it might be
On Wed, 20 Feb 2008 22:44:29 +0100
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-02-20 at 13:07 -0800, Arjan van de Ven wrote:
> > On Wed, 20 Feb 2008 21:58:42 +0100
> > Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> >
> > >
> > &g
On Wed, 20 Feb 2008 21:58:42 +0100
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-02-20 at 11:26 -0800, Arjan van de Ven wrote:
>
> > feel free to reinvent a whole GUI just to avoid a 200 line kernel
> > module. sysprof is here. it works.
>
> >
On Wed, 20 Feb 2008 19:53:42 +0100
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-02-20 at 10:39 -0800, Arjan van de Ven wrote:
> > On Wed, 20 Feb 2008 19:16:15 +0100
> > Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> >
> > >
> > &g
On Wed, 20 Feb 2008 19:16:15 +0100
Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-02-19 at 12:37 -0800, Arjan van de Ven wrote:
> > From: Soren Sandmann <[EMAIL PROTECTED]>
> > Subject: [PATCH] x86: add the debugfs interface for the sysprof tool
>
On Wed, 20 Feb 2008 19:16:15 +0100
Peter Zijlstra [EMAIL PROTECTED] wrote:
On Tue, 2008-02-19 at 12:37 -0800, Arjan van de Ven wrote:
From: Soren Sandmann [EMAIL PROTECTED]
Subject: [PATCH] x86: add the debugfs interface for the sysprof tool
The sysprof tool is a very easy to use GUI
On Wed, 20 Feb 2008 19:53:42 +0100
Peter Zijlstra [EMAIL PROTECTED] wrote:
On Wed, 2008-02-20 at 10:39 -0800, Arjan van de Ven wrote:
On Wed, 20 Feb 2008 19:16:15 +0100
Peter Zijlstra [EMAIL PROTECTED] wrote:
On Tue, 2008-02-19 at 12:37 -0800, Arjan van de Ven wrote:
From
On Wed, 20 Feb 2008 21:58:42 +0100
Peter Zijlstra [EMAIL PROTECTED] wrote:
On Wed, 2008-02-20 at 11:26 -0800, Arjan van de Ven wrote:
feel free to reinvent a whole GUI just to avoid a 200 line kernel
module. sysprof is here. it works.
the gui is REALLY nice.
I guess we have
On Wed, 20 Feb 2008 22:44:29 +0100
Peter Zijlstra [EMAIL PROTECTED] wrote:
On Wed, 2008-02-20 at 13:07 -0800, Arjan van de Ven wrote:
On Wed, 20 Feb 2008 21:58:42 +0100
Peter Zijlstra [EMAIL PROTECTED] wrote:
On Wed, 2008-02-20 at 11:26 -0800, Arjan van de Ven wrote:
feel
On Tue, 19 Feb 2008 22:55:01 +0100
Frans Pop <[EMAIL PROTECTED]> wrote:
> On Sunday 17 February 2008, Adrian Bunk wrote:
> > The real problem is that the kernel seems to lack functionality you
> > require for doing some work.
>
> Not sure how you reached that conclusion.
>
> > Why does your
nshots on this tool.
Sysprof needs a 200 line kernel module to do it's work, this
module puts some simple profiling data into debugfs.
Signed-off-by: Soren Sandmann <[EMAIL PROTECTED]>
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
---
arch/x86/Kconfig.debug| 10 ++
arch/x86/kerne
on this tool.
Sysprof needs a 200 line kernel module to do it's work, this
module puts some simple profiling data into debugfs.
Signed-off-by: Soren Sandmann [EMAIL PROTECTED]
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
---
arch/x86/Kconfig.debug| 10 ++
arch/x86/kernel/Makefile |2
On Tue, 19 Feb 2008 22:55:01 +0100
Frans Pop [EMAIL PROTECTED] wrote:
On Sunday 17 February 2008, Adrian Bunk wrote:
The real problem is that the kernel seems to lack functionality you
require for doing some work.
Not sure how you reached that conclusion.
Why does your work on the
On Tue, 19 Feb 2008 13:33:53 +1100
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> Actually one thing I don't like about gcc is that I think it still
> emits cmovs for likely/unlikely branches, which is silly (the gcc
> developers seem to be in love with that instruction). If that goes
> away, then
Laurent Riffard wrote:
ioremap: trying to map RAM page at 0 <===
Completing Region/Field/Buffer/Package
initialization:
Hope this helps.
actually... it helps a lot.
I'll cook up a patch for this now :)
thanks for testing so
On Mon, 18 Feb 2008 21:58:42 +0100
Jean Delvare <[EMAIL PROTECTED]> wrote:
> On Tue, 19 Feb 2008 07:42:03 +1100, Benjamin Herrenschmidt wrote:
> >
> > > Maybe Christian's patch can be improved to not do the check on
> > > these? As long as /dev/port exists, it seems reasonable that the
> > >
c346400b372a99a4158fce3ea45234bcf947bdf8 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <[EMAIL PROTECTED]>
Date: Mon, 18 Feb 2008 08:01:47 -0800
Subject: [PATCH] More diagnostic output for the ioremap WARN_ON
now that ACPI seems to have triggered this WARN_ON.. we need to know
which address it triggers on to b
On Mon, 18 Feb 2008 10:53:42 -0800
Roland Dreier <[EMAIL PROTECTED]> wrote:
> AFAIK mapping PCI memory WB is not allowed, so WC is really our only
> choice.
afaik that depends on the BAR being prefetchable or not.
(and by your argument, ioremap_cached() would not be useful, and since that
was,
On Mon, 18 Feb 2008 18:40:50 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> > I've yet to see a user who wants WC. Lets face it, WC *sucks*. This
> > is why the folks who care about performance (the graphics guys)
> > stopped using it.
>
> WC for main memory or WC for mmio spaces ?
if you mean
On Mon, 18 Feb 2008 13:11:06 -0500
[EMAIL PROTECTED] wrote:
> On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
>
> > __builtin_expect() is useful on FRV where you _have_ to give each
> > branch and conditional branch instruction a measure of probability
> > whether the branch will be taken.
On Mon, 18 Feb 2008 19:52:28 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> > I've yet to see a user who wants WC. Lets face it, WC *sucks*. This
> > is why
>
> Interesting.
>
> > the folks who care about performance (the graphics guys) stopped
> > using it.
>
> I didn't know this. What do
On Mon, 18 Feb 2008 18:11:59 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> > to do is go via an intermediate UC state and the really expensive
> > process from the manual is not needed.
>
> Ok then you're proposing to use a even more expensive operation just
> to patch this over. I guess that
On Mon, 18 Feb 2008 04:59:18 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Feb 2008 14:47:01 +0800 "Zhang, Yanmin"
> <[EMAIL PROTECTED]> wrote:
>
> > Call Trace:
> > [] ? __alloc_skb+0x31/0x121
> > [] ? sock_alloc_send_skb+0x77/0x1d2
> > [] ? autoremove_wake_function+0x0/0x2e
>
On Mon, 18 Feb 2008 12:24:53 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> >
> > question: can we please list the last known good version for each
> > entry? Since these are all regressions (right?) that information
> > ought to be available and usually helps down in narrowing causes..
On Mon, 18 Feb 2008 13:31:48 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
> >
> > the initial plan was for a depreciation period. Sadly it was
> > untenable since the API was changing entirely to fix bugs and a
On Mon, 18 Feb 2008 12:24:53 +0100
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
question: can we please list the last known good version for each
entry? Since these are all regressions (right?) that information
ought to be available and usually helps down in narrowing causes..
Well,
On Mon, 18 Feb 2008 13:31:48 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
the initial plan was for a depreciation period. Sadly it was
untenable since the API was changing entirely to fix bugs and add a
really important feature (the ability
On Mon, 18 Feb 2008 04:59:18 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 15 Feb 2008 14:47:01 +0800 Zhang, Yanmin
[EMAIL PROTECTED] wrote:
Call Trace:
[805e0024] ? __alloc_skb+0x31/0x121
[805dc389] ? sock_alloc_send_skb+0x77/0x1d2
[80243897] ?
On Mon, 18 Feb 2008 18:11:59 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
to do is go via an intermediate UC state and the really expensive
process from the manual is not needed.
Ok then you're proposing to use a even more expensive operation just
to patch this over. I guess that will work as
On Mon, 18 Feb 2008 19:52:28 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
I've yet to see a user who wants WC. Lets face it, WC *sucks*. This
is why
Interesting.
the folks who care about performance (the graphics guys) stopped
using it.
I didn't know this. What do they do instead?
On Mon, 18 Feb 2008 13:11:06 -0500
[EMAIL PROTECTED] wrote:
On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said:
__builtin_expect() is useful on FRV where you _have_ to give each
branch and conditional branch instruction a measure of probability
whether the branch will be taken.
What
On Mon, 18 Feb 2008 18:40:50 +
Alan Cox [EMAIL PROTECTED] wrote:
I've yet to see a user who wants WC. Lets face it, WC *sucks*. This
is why the folks who care about performance (the graphics guys)
stopped using it.
WC for main memory or WC for mmio spaces ?
if you mean 'framebuffer'
On Mon, 18 Feb 2008 10:53:42 -0800
Roland Dreier [EMAIL PROTECTED] wrote:
AFAIK mapping PCI memory WB is not allowed, so WC is really our only
choice.
afaik that depends on the BAR being prefetchable or not.
(and by your argument, ioremap_cached() would not be useful, and since that
was,
c346400b372a99a4158fce3ea45234bcf947bdf8 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven [EMAIL PROTECTED]
Date: Mon, 18 Feb 2008 08:01:47 -0800
Subject: [PATCH] More diagnostic output for the ioremap WARN_ON
now that ACPI seems to have triggered this WARN_ON.. we need to know
which address it triggers on to be able
On Mon, 18 Feb 2008 21:58:42 +0100
Jean Delvare [EMAIL PROTECTED] wrote:
On Tue, 19 Feb 2008 07:42:03 +1100, Benjamin Herrenschmidt wrote:
Maybe Christian's patch can be improved to not do the check on
these? As long as /dev/port exists, it seems reasonable that the
kernel should
501 - 600 of 3577 matches
Mail list logo
