Re: [PATCH] x86: Implement __WARN using UD0

On 2/23/2017 5:28 AM, Peter Zijlstra wrote: By using "UD0" for WARNs we remove the function call and its possible __FILE__ and __LINE__ immediate arguments from the instruction stream. Total image size will not change much, what we win in the instruction stream we'll loose because of the

Re: [PATCH] x86: Implement __WARN using UD0

On 2/23/2017 5:28 AM, Peter Zijlstra wrote: By using "UD0" for WARNs we remove the function call and its possible __FILE__ and __LINE__ immediate arguments from the instruction stream. Total image size will not change much, what we win in the instruction stream we'll loose because of the

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 9:54 AM, Thomas Garnier wrote: That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet. don't we write to

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 9:54 AM, Thomas Garnier wrote: That's my goal too. I started by doing a RO remap and got couple problems with hibernation. I can try again for the next iteration or delay it for another patch. I also need to look at KVM GDT usage, I am not familiar with it yet. don't we write to

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 8:40 AM, Thomas Garnier wrote: Well, it happens only when KASLR memory randomization is enabled. Do you think it should have a separate config option? no I would want it a runtime option "sgdt from ring 3" is going away with UMIP (and is already possibly gone in virtual

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 8:40 AM, Thomas Garnier wrote: Well, it happens only when KASLR memory randomization is enabled. Do you think it should have a separate config option? no I would want it a runtime option "sgdt from ring 3" is going away with UMIP (and is already possibly gone in virtual

Re: [PATCH 1/3] cpuidle/menu: stop seeking deeper idle if current state is too deep

On 1/5/2017 7:43 AM, Rik van Riel wrote: On Thu, 2017-01-05 at 23:29 +0800, Alex Shi wrote: The obsolete commit 71abbbf85 want to introduce a dynamic cstates, but it was removed for long time. Just left the nonsense deeper cstate checking. Since all target_residency and exit_latency are going

Re: [PATCH 1/3] cpuidle/menu: stop seeking deeper idle if current state is too deep

On 1/5/2017 7:43 AM, Rik van Riel wrote: On Thu, 2017-01-05 at 23:29 +0800, Alex Shi wrote: The obsolete commit 71abbbf85 want to introduce a dynamic cstates, but it was removed for long time. Just left the nonsense deeper cstate checking. Since all target_residency and exit_latency are going

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 12:11 AM, Ingo Molnar wrote: * Thomas Garnier wrote: Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an

Re: [RFC] x86/mm/KASLR: Remap GDTs at fixed location

On 1/5/2017 12:11 AM, Ingo Molnar wrote: * Thomas Garnier wrote: Each processor holds a GDT in its per-cpu structure. The sgdt instruction gives the base address of the current GDT. This address can be used to bypass KASLR memory randomization. With another bug, an attacker could target

Re: [PATCH] proc: Fix timerslack_ns CAP_SYS_NICE check when adjusting self

On 8/10/2016 12:03 PM, John Stultz wrote: I wasn't entierly sure. I didn't think PR_SET_TIMERSLACK has a security hook, but looking again I now see the top-level security_task_prctl() check, so maybe not skipping it in this case would be good? the easy fix would be to add back the ptrace

Re: [PATCH] proc: Fix timerslack_ns CAP_SYS_NICE check when adjusting self

On 8/10/2016 12:03 PM, John Stultz wrote: I wasn't entierly sure. I didn't think PR_SET_TIMERSLACK has a security hook, but looking again I now see the top-level security_task_prctl() check, so maybe not skipping it in this case would be good? the easy fix would be to add back the ptrace

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

On 7/14/2016 10:45 AM, Kees Cook wrote: On Thu, Jul 14, 2016 at 9:09 AM, John Stultz wrote: On Thu, Jul 14, 2016 at 5:48 AM, Serge E. Hallyn wrote: Quoting Kees Cook (keesc...@chromium.org): I think the original CAP_SYS_NICE should be fine. A

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

On 7/14/2016 10:45 AM, Kees Cook wrote: On Thu, Jul 14, 2016 at 9:09 AM, John Stultz wrote: On Thu, Jul 14, 2016 at 5:48 AM, Serge E. Hallyn wrote: Quoting Kees Cook (keesc...@chromium.org): I think the original CAP_SYS_NICE should be fine. A malicious CAP_SYS_NICE process can do plenty of

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

On 7/14/2016 5:48 AM, Serge E. Hallyn wrote: Can someone give a detailed explanation of what you could do with the new timerslack feature and compare it to what you can do with sys_nice? what you can do with the timerslack feature is add upto 4 seconds of extra time/delay on top of each

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

On 7/14/2016 5:48 AM, Serge E. Hallyn wrote: Can someone give a detailed explanation of what you could do with the new timerslack feature and compare it to what you can do with sys_nice? what you can do with the timerslack feature is add upto 4 seconds of extra time/delay on top of each

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

On 7/13/2016 8:39 PM, Kees Cook wrote: So I worry I'm a bit stuck here. For general systems, CAP_SYS_NICE is too low a level of privilege to set a tasks timerslack, but apparently CAP_SYS_PTRACE is too high a privilege for Android's system_server to require just to set a tasks timerslack

Re: [PATCH 2/2] proc: Add /proc//timerslack_ns interface

On 7/13/2016 8:39 PM, Kees Cook wrote: So I worry I'm a bit stuck here. For general systems, CAP_SYS_NICE is too low a level of privilege to set a tasks timerslack, but apparently CAP_SYS_PTRACE is too high a privilege for Android's system_server to require just to set a tasks timerslack

Re: [PATCH 1/8] x86: don't use module.h just for AUTHOR / LICENSE tags

contained at the top of the file in the comments. Cc: Arjan van de Ven <ar...@linux.intel.com> Acked-by: Arjan van de Ven <ar...@linux.intel.com> original these were tested as modules, but they really shouldn't be modules in the normal kernel (and aren't per Kconfig)

Re: [PATCH 1/8] x86: don't use module.h just for AUTHOR / LICENSE tags

contained at the top of the file in the comments. Cc: Arjan van de Ven Acked-by: Arjan van de Ven original these were tested as modules, but they really shouldn't be modules in the normal kernel (and aren't per Kconfig)

Re: [patch V2 00/20] timer: Refactor the timer wheel

On Sun, Jun 26, 2016 at 12:00 PM, Pavel Machek wrote: > > Umm. I'm not sure if you should be designing kernel... > > I have alarm clock application. It does sleep(60) many times till its > time to wake me up. I'll be very angry if sleep(60) takes 65 seconds > without some very, very

Re: [patch V2 00/20] timer: Refactor the timer wheel

On Sun, Jun 26, 2016 at 12:00 PM, Pavel Machek wrote: > > Umm. I'm not sure if you should be designing kernel... > > I have alarm clock application. It does sleep(60) many times till its > time to wake me up. I'll be very angry if sleep(60) takes 65 seconds > without some very, very good reason.

Re: [patch V2 00/20] timer: Refactor the timer wheel

so is there really an issue? sounds like KISS principle can apply On Mon, Jun 20, 2016 at 7:46 AM, Thomas Gleixner <t...@linutronix.de> wrote: > On Mon, 20 Jun 2016, Arjan van de Ven wrote: >> On Mon, Jun 20, 2016 at 6:56 AM, Thomas Gleixner <t...@linutronix.de> wrote:

Re: [patch V2 00/20] timer: Refactor the timer wheel

so is there really an issue? sounds like KISS principle can apply On Mon, Jun 20, 2016 at 7:46 AM, Thomas Gleixner wrote: > On Mon, 20 Jun 2016, Arjan van de Ven wrote: >> On Mon, Jun 20, 2016 at 6:56 AM, Thomas Gleixner wrote: >> > >> > 2) Cut off at 37hrs

Re: [patch V2 00/20] timer: Refactor the timer wheel

On Mon, Jun 20, 2016 at 6:56 AM, Thomas Gleixner wrote: > > 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a 1000HZ >option so datacenter folks can use this and people who don't care and want >better batching for power can use the 4ms thingy. if

Re: [patch V2 00/20] timer: Refactor the timer wheel

On Mon, Jun 20, 2016 at 6:56 AM, Thomas Gleixner wrote: > > 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a 1000HZ >option so datacenter folks can use this and people who don't care and want >better batching for power can use the 4ms thingy. if there really is one

Re: initialize a mutex into locked state?

On 6/17/2016 7:54 AM, Oleg Drokin wrote: Yes, we can add all sorts of checks that have various impacts on code readability, we can also move code around that also have code readability and CPU impact. But in my discussion with Arjan he said this is a new use case that was not met before and

Re: initialize a mutex into locked state?

On 6/17/2016 7:54 AM, Oleg Drokin wrote: Yes, we can add all sorts of checks that have various impacts on code readability, we can also move code around that also have code readability and CPU impact. But in my discussion with Arjan he said this is a new use case that was not met before and

Re: [patch V2 00/20] timer: Refactor the timer wheel

>To achieve this capacity with HZ=1000 without increasing the storage size >by another level, we reduced the granularity of the first wheel level from >1ms to 4ms. According to our data, there is no user which relies on that >1ms granularity and 99% of those timers are canceled

Re: [patch V2 00/20] timer: Refactor the timer wheel

>To achieve this capacity with HZ=1000 without increasing the storage size >by another level, we reduced the granularity of the first wheel level from >1ms to 4ms. According to our data, there is no user which relies on that >1ms granularity and 99% of those timers are canceled

Re: [patch 13/20] timer: Switch to a non cascading wheel

<t...@linutronix.de> wrote: > On Wed, 15 Jun 2016, Thomas Gleixner wrote: >> On Wed, 15 Jun 2016, Arjan van de Ven wrote: >> > what would 1 more timer wheel do? >> >> Waste storage space and make the collection of expired timers more expensive. >> >

Re: [patch 13/20] timer: Switch to a non cascading wheel

wrote: > On Wed, 15 Jun 2016, Thomas Gleixner wrote: >> On Wed, 15 Jun 2016, Arjan van de Ven wrote: >> > what would 1 more timer wheel do? >> >> Waste storage space and make the collection of expired timers more expensive. >> >> The selection of

Re: [patch 13/20] timer: Switch to a non cascading wheel

what would 1 more timer wheel do? On Wed, Jun 15, 2016 at 7:53 AM, Thomas Gleixner wrote: > On Tue, 14 Jun 2016, Eric Dumazet wrote: >> Original TCP RFCs tell timeout is infinite ;) >> >> Practically, conntrack has a 5 days timeout, but I really doubt anyone >> expects an

Re: [patch 13/20] timer: Switch to a non cascading wheel

what would 1 more timer wheel do? On Wed, Jun 15, 2016 at 7:53 AM, Thomas Gleixner wrote: > On Tue, 14 Jun 2016, Eric Dumazet wrote: >> Original TCP RFCs tell timeout is infinite ;) >> >> Practically, conntrack has a 5 days timeout, but I really doubt anyone >> expects an idle TCP flow to stay

Re: [patch 13/20] timer: Switch to a non cascading wheel

evaluating a 120 hours timer ever 37 hours to see if it should fire... not too horrid. On Tue, Jun 14, 2016 at 9:28 AM, Thomas Gleixner wrote: > On Tue, 14 Jun 2016, Ingo Molnar wrote: >> * Thomas Gleixner wrote: >> > On Mon, 13 Jun 2016, Peter Zijlstra

Re: [patch 13/20] timer: Switch to a non cascading wheel

evaluating a 120 hours timer ever 37 hours to see if it should fire... not too horrid. On Tue, Jun 14, 2016 at 9:28 AM, Thomas Gleixner wrote: > On Tue, 14 Jun 2016, Ingo Molnar wrote: >> * Thomas Gleixner wrote: >> > On Mon, 13 Jun 2016, Peter Zijlstra wrote: >> > > On Mon, Jun 13, 2016 at

Re: [patch 04/20] cpufreq/powernv: Initialize timer as pinned

On Mon, Jun 13, 2016 at 1:40 AM, Thomas Gleixner wrote: > mod_timer(>timer, jiffies + msecs_to_jiffies(timer_interval)); are you sure this is right? the others did not get replaced by mod_timer().. (and this is more evidence that a relative API in msecs is what drivers really

Re: [patch 04/20] cpufreq/powernv: Initialize timer as pinned

On Mon, Jun 13, 2016 at 1:40 AM, Thomas Gleixner wrote: > mod_timer(>timer, jiffies + msecs_to_jiffies(timer_interval)); are you sure this is right? the others did not get replaced by mod_timer().. (and this is more evidence that a relative API in msecs is what drivers really want)

Re: [patch 06/20] drivers/tty/metag_da: Initialize timer as pinned

I know it's not related to this patch, but it'd be nice to, as you're changing the api name anyway, make a mod_pinned_relative() so that more direct users of jiffies can go away... or even better, mod_pinned_relative_ms() so that these drivers also do not need to care about HZ. On Mon, Jun 13,

Re: [patch 06/20] drivers/tty/metag_da: Initialize timer as pinned

I know it's not related to this patch, but it'd be nice to, as you're changing the api name anyway, make a mod_pinned_relative() so that more direct users of jiffies can go away... or even better, mod_pinned_relative_ms() so that these drivers also do not need to care about HZ. On Mon, Jun 13,

Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]

Oh, and this was with acpi_idle. This machine already failed to resume from S3 with intel_idle since forever, as detailed in https://bugzilla.kernel.org/show_bug.cgi?id=107151 but acpi_idle worked fine until now. can you disable (in sysfs) all C states other than C0/C1 and see if that makes

Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]

Oh, and this was with acpi_idle. This machine already failed to resume from S3 with intel_idle since forever, as detailed in https://bugzilla.kernel.org/show_bug.cgi?id=107151 but acpi_idle worked fine until now. can you disable (in sysfs) all C states other than C0/C1 and see if that makes

Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]

On 5/11/2016 3:19 AM, Ville Syrjälä wrote: Oh, and this was with acpi_idle. This machine already failed to resume from S3 with intel_idle since forever, as detailed in https://bugzilla.kernel.org/show_bug.cgi?id=107151 but acpi_idle worked fine until now. this is the important clue part

Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]

On 5/11/2016 3:19 AM, Ville Syrjälä wrote: Oh, and this was with acpi_idle. This machine already failed to resume from S3 with intel_idle since forever, as detailed in https://bugzilla.kernel.org/show_bug.cgi?id=107151 but acpi_idle worked fine until now. this is the important clue part

Re: [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception

On 4/4/2016 8:32 AM, Andy Lutomirski wrote: Adding locking would be easy enough, wouldn't it? But do any platforms really boot a second CPU before switching to real printk? Given that I see all the smpboot stuff in dmesg, I guess real printk happens first. I admit I haven't actually checked.

Re: [PATCH v5 3/9] x86/head: Move early exception panic code into early_fixup_exception

On 4/4/2016 8:32 AM, Andy Lutomirski wrote: Adding locking would be easy enough, wouldn't it? But do any platforms really boot a second CPU before switching to real printk? Given that I see all the smpboot stuff in dmesg, I guess real printk happens first. I admit I haven't actually checked.

Re: [PATCH] x86: Enable full randomization on i386 and X86_32.

Arjan, or other folks, can you remember why x86_32 disabled mmap randomization here? There doesn't seem to be a good reason for it that I see. for unlimited stack it got really messy with threaded apps. anyway, I don't mind seeing if this will indeed work, with time running out where 32 bit is

Re: [PATCH] x86: Enable full randomization on i386 and X86_32.

Arjan, or other folks, can you remember why x86_32 disabled mmap randomization here? There doesn't seem to be a good reason for it that I see. for unlimited stack it got really messy with threaded apps. anyway, I don't mind seeing if this will indeed work, with time running out where 32 bit is

Re: [PATCH v2] arm64: add alignment fault hanling

On 2/16/2016 10:50 AM, Linus Torvalds wrote: On Tue, Feb 16, 2016 at 9:04 AM, Will Deacon wrote: [replying to self and adding some x86 people] Background: Euntaik reports a problem where userspace has ended up with a memory page mapped adjacent to an MMIO page (e.g. from

Re: [PATCH v2] arm64: add alignment fault hanling

On 2/16/2016 10:50 AM, Linus Torvalds wrote: On Tue, Feb 16, 2016 at 9:04 AM, Will Deacon wrote: [replying to self and adding some x86 people] Background: Euntaik reports a problem where userspace has ended up with a memory page mapped adjacent to an MMIO page (e.g. from /dev/mem or a PCI

Re: [PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread.

and most of the RT guys would only tolerate a little bit of it is there any real/practial use of going longer than 4 seconds? if there is then yeah fixing it makes sense. if it's just theoretical... shrug... 32 bit systems have a bunch of other limits/differences a well. So I'd think it would

Re: [PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread.

On 2/5/2016 4:51 PM, John Stultz wrote: On Fri, Feb 5, 2016 at 2:35 PM, John Stultz wrote: On Fri, Feb 5, 2016 at 12:50 PM, Andrew Morton wrote: On Fri, 5 Feb 2016 12:44:04 -0800 Kees Cook wrote: Could this be exposed as a writable /proc entry instead? Like the oom_* stuff?

Re: [PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread.

On 2/5/2016 4:51 PM, John Stultz wrote: On Fri, Feb 5, 2016 at 2:35 PM, John Stultz wrote: On Fri, Feb 5, 2016 at 12:50 PM, Andrew Morton wrote: On Fri, 5 Feb 2016 12:44:04 -0800 Kees Cook wrote: Could this be

Re: [PATCH] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread.

and most of the RT guys would only tolerate a little bit of it is there any real/practial use of going longer than 4 seconds? if there is then yeah fixing it makes sense. if it's just theoretical... shrug... 32 bit systems have a bunch of other limits/differences a well. So I'd think it would

Re: [RFC][PATCH v2] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread.

arbitrary apps do not change the timer slack for other apps. Acked-by: Arjan van de Ven only slight concern is the locking around the value of the field in the task struct, but nobody does read-modify-write on it, so they'll get either the new or the old version, which should be ok. (until now only

Re: [RFC][PATCH v2] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread.

sk, so that we can ensure arbitrary apps do not change the timer slack for other apps. Acked-by: Arjan van de Ven <ar...@linux.intel.com> only slight concern is the locking around the value of the field in the task struct, but nobody does read-modify-write on it, so they'll get ei

Re: 4.4-rc5: ugly warn on: 5 W+X pages found

On 12/14/2015 11:56 PM, Pavel Machek wrote: On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote: That's weird. The only API to do that seems to be manually setting kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is kmap_prot a variable on x86 at all? It has exactly one writer

Re: 4.4-rc5: ugly warn on: 5 W+X pages found

On 12/14/2015 11:56 PM, Pavel Machek wrote: On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote: That's weird. The only API to do that seems to be manually setting kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is kmap_prot a variable on x86 at all? It has exactly one writer

Re: 4.4-rc5: ugly warn on: 5 W+X pages found

That's weird. The only API to do that seems to be manually setting kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is kmap_prot a variable on x86 at all? It has exactly one writer, and that's the code that initializes it in the first place. Shouldn't we #define kmap_prot

Re: 4.4-rc5: ugly warn on: 5 W+X pages found

That's weird. The only API to do that seems to be manually setting kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that. (Why is kmap_prot a variable on x86 at all? It has exactly one writer, and that's the code that initializes it in the first place. Shouldn't we #define kmap_prot

Re: [PATCH 3/4] sched: introduce synchronized idle injection

On 11/18/2015 7:44 AM, Morten Rasmussen wrote: I would not necessarily want to punish all cpus system-wide if we have local overheating in one corner. If would rather have it apply to only the overheating socket in a multi-socket machine and only the big cores in a big.LITTLE system. most of

Re: [PATCH 3/4] sched: introduce synchronized idle injection

On 11/18/2015 12:36 AM, Ingo Molnar wrote: What will such throttling do to latencies, as observed by user-space tasks? What's the typical expected frequency of the throttling frequency that you are targeting? for this to meaningfully reduce power consumption, deep system power states need

Re: [PATCH 3/4] sched: introduce synchronized idle injection

On 11/18/2015 7:44 AM, Morten Rasmussen wrote: I would not necessarily want to punish all cpus system-wide if we have local overheating in one corner. If would rather have it apply to only the overheating socket in a multi-socket machine and only the big cores in a big.LITTLE system. most of

Re: [PATCH 3/4] sched: introduce synchronized idle injection

On 11/18/2015 12:36 AM, Ingo Molnar wrote: What will such throttling do to latencies, as observed by user-space tasks? What's the typical expected frequency of the throttling frequency that you are targeting? for this to meaningfully reduce power consumption, deep system power states need

Re: [PATCH 2/4] timer: relax tick stop in idle entry

On 11/16/2015 6:53 PM, Paul E. McKenney wrote: Fair point. When in the five-jiffy throttling state, what can wake up a CPU? In an earlier version of this proposal, the answer was "nothing", but maybe that has changed. device interrupts are likely to wake the cpus. -- To unsubscribe from

Re: [PATCH 2/4] timer: relax tick stop in idle entry

On 11/16/2015 3:28 PM, Paul E. McKenney wrote: Is this mostly an special-purpose embedded thing, or do you expect distros to be enabling this? If the former, I suggest CONFIG_RCU_NOCB_CPU_ALL, but if distros are doing this for general-purpose workloads, I instead suggest CONFIG_RCU_FAST_NO_HZ.

Re: [PATCH 2/4] timer: relax tick stop in idle entry

On 11/16/2015 3:28 PM, Paul E. McKenney wrote: Is this mostly an special-purpose embedded thing, or do you expect distros to be enabling this? If the former, I suggest CONFIG_RCU_NOCB_CPU_ALL, but if distros are doing this for general-purpose workloads, I instead suggest CONFIG_RCU_FAST_NO_HZ.

Re: [PATCH 2/4] timer: relax tick stop in idle entry

On 11/16/2015 6:53 PM, Paul E. McKenney wrote: Fair point. When in the five-jiffy throttling state, what can wake up a CPU? In an earlier version of this proposal, the answer was "nothing", but maybe that has changed. device interrupts are likely to wake the cpus. -- To unsubscribe from

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On 11/5/2015 7:32 AM, Jacob Pan wrote: On Thu, 5 Nov 2015 15:33:32 +0100 Peter Zijlstra wrote: On Thu, Nov 05, 2015 at 06:22:58AM -0800, Arjan van de Ven wrote: On 11/5/2015 2:09 AM, Peter Zijlstra wrote: I can see such a scheme having a fairly big impact on latency, esp. with forced

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On 11/5/2015 6:33 AM, Peter Zijlstra wrote: On Thu, Nov 05, 2015 at 06:22:58AM -0800, Arjan van de Ven wrote: On 11/5/2015 2:09 AM, Peter Zijlstra wrote: I can see such a scheme having a fairly big impact on latency, esp. with forced idleness such as this. That's not going to be popular

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On 11/5/2015 2:09 AM, Peter Zijlstra wrote: I can see such a scheme having a fairly big impact on latency, esp. with forced idleness such as this. That's not going to be popular for many workloads. idle injection is a last ditch effort in thermal management, before this gets used the hardware

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On 11/5/2015 2:09 AM, Peter Zijlstra wrote: I can see such a scheme having a fairly big impact on latency, esp. with forced idleness such as this. That's not going to be popular for many workloads. idle injection is a last ditch effort in thermal management, before this gets used the hardware

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On 11/5/2015 7:32 AM, Jacob Pan wrote: On Thu, 5 Nov 2015 15:33:32 +0100 Peter Zijlstra <pet...@infradead.org> wrote: On Thu, Nov 05, 2015 at 06:22:58AM -0800, Arjan van de Ven wrote: On 11/5/2015 2:09 AM, Peter Zijlstra wrote: I can see such a scheme having a fairly big impact on l

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On 11/5/2015 6:33 AM, Peter Zijlstra wrote: On Thu, Nov 05, 2015 at 06:22:58AM -0800, Arjan van de Ven wrote: On 11/5/2015 2:09 AM, Peter Zijlstra wrote: I can see such a scheme having a fairly big impact on latency, esp. with forced idleness such as this. That's not going to be popular

Re: [PATCH 3/3] cpuidle,menu: smooth out measured_us calculation

measured_us, will reduce the error. there is no perfect answer for this issue; but at least this makes the situation a lot better, so Acked-by: Arjan van de Ven -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling to 20us

Acked-by: Arjan van de Ven -- 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 Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 2/3] cpuidle,menu: use interactivity_req to disable polling

performance and power on those CPUs if we are expecting a very low wakeup latency. Disable polling based on the estimated interactivity requirement, not on the time to the next timer interrupt. good catch! Acked-by: Arjan van de Ven -- To unsubscribe from this list: send the line "unsubs

Re: [PATCH 2/3] cpuidle,menu: use interactivity_req to disable polling

would be good to not waste performance and power on those CPUs if we are expecting a very low wakeup latency. Disable polling based on the estimated interactivity requirement, not on the time to the next timer interrupt. good catch! Acked-by: Arjan van de Ven <ar...@linux.intel.com> -- To unsu

Re: [PATCH 1/3] cpuidle,x86: increase forced cut-off for polling to 20us

Acked-by: Arjan van de Ven <ar...@linux.intel.com> -- 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 Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 3/3] cpuidle,menu: smooth out measured_us calculation

measured_us, will reduce the error. there is no perfect answer for this issue; but at least this makes the situation a lot better, so Acked-by: Arjan van de Ven <ar...@linux.intel.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a m

Re: [tip:x86/mm] x86/mm: Warn on W^X mappings

On 10/8/2015 7:57 AM, Borislav Petkov wrote: + pr_info("x86/mm: Checked W+X mappings: passed, no W+X pages found.\n"); Do we really want to issue anything here in the success case? IMO, we should be quiet if the check passes and only scream when something's wrong... I would

Re: [tip:x86/mm] x86/mm: Warn on W^X mappings

On 10/8/2015 7:57 AM, Borislav Petkov wrote: + pr_info("x86/mm: Checked W+X mappings: passed, no W+X pages found.\n"); Do we really want to issue anything here in the success case? IMO, we should be quiet if the check passes and only scream when something's wrong... I would

Re: [tip:x86/mm] x86/mm: Warn on W^X mappings

be enabled without exposing the debugfs interface. Switch EFI_PGT_DUMP to using X86_PTDUMP_CORE so that it also does not require enabling the debugfs interface. I like it, so Acked-by: Arjan van de Ven I also have/had an old userland script to do similar checks but using the debugfs interface

Re: [tip:x86/mm] x86/mm: Warn on W^X mappings

the debugfs interface, so that DEBUG_WX can be enabled without exposing the debugfs interface. Switch EFI_PGT_DUMP to using X86_PTDUMP_CORE so that it also does not require enabling the debugfs interface. I like it, so Acked-by: Arjan van de Ven <ar...@linux.intel.com> I also have/h

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On 9/21/2015 9:36 AM, Linus Torvalds wrote: On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote: Linus, what's your preference? So quite frankly, is there any reason we don't just implement native_read_msr() as just unsigned long long native_read_msr(unsigned int msr) { int

Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On 9/21/2015 9:36 AM, Linus Torvalds wrote: On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote: Linus, what's your preference? So quite frankly, is there any reason we don't just implement native_read_msr() as just unsigned long long native_read_msr(unsigned int msr)

Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 9/17/2015 8:29 AM, Paolo Bonzini wrote: On 17/09/2015 17:27, Arjan van de Ven wrote: ( We should double check that rdmsr()/wrmsr() results are never left uninitialized, but are set to zero or so, for cases where the return code is not checked. ) It sure looks like

Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

( We should double check that rdmsr()/wrmsr() results are never left uninitialized, but are set to zero or so, for cases where the return code is not checked. ) It sure looks like native_read_msr_safe doesn't clear the output if the rdmsr fails. I'd suggest to return some poison not

Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

( We should double check that rdmsr()/wrmsr() results are never left uninitialized, but are set to zero or so, for cases where the return code is not checked. ) It sure looks like native_read_msr_safe doesn't clear the output if the rdmsr fails. I'd suggest to return some poison not

Re: [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 9/17/2015 8:29 AM, Paolo Bonzini wrote: On 17/09/2015 17:27, Arjan van de Ven wrote: ( We should double check that rdmsr()/wrmsr() results are never left uninitialized, but are set to zero or so, for cases where the return code is not checked. ) It sure looks like

Re: V4.0.x fails to create /dev/rtc0 on Winbook TW100 when CONFIG_PINCTRL_BAYTRAIL is set, bisected to commit 7486341

On 7/11/2015 11:26 AM, Porteus Kiosk wrote: Hello Arjan, We need it for setting up the time in the hardware clock through the 'hwclock' command. Thank you. hmm thinking about it after coffee... there is an RTC that can be exposed to userspace. hrmpf. Wonder why its not there for you

Re: V4.0.x fails to create /dev/rtc0 on Winbook TW100 when CONFIG_PINCTRL_BAYTRAIL is set, bisected to commit 7486341

On 7/11/2015 11:21 AM, Arjan van de Ven wrote: On 7/11/2015 10:59 AM, Larry Finger wrote: On a Winbook TW100 BayTrail tablet, kernel 4.0 and later do not create /dev/rtc0 when CONFIG_PINCTRL_BAYTRAIL is set in the configuration. Removing this option from the config creates a real-time clock

Re: V4.0.x fails to create /dev/rtc0 on Winbook TW100 when CONFIG_PINCTRL_BAYTRAIL is set, bisected to commit 7486341

On 7/11/2015 10:59 AM, Larry Finger wrote: On a Winbook TW100 BayTrail tablet, kernel 4.0 and later do not create /dev/rtc0 when CONFIG_PINCTRL_BAYTRAIL is set in the configuration. Removing this option from the config creates a real-time clock; however, it is no longer possible to get the

Re: V4.0.x fails to create /dev/rtc0 on Winbook TW100 when CONFIG_PINCTRL_BAYTRAIL is set, bisected to commit 7486341

On 7/11/2015 11:21 AM, Arjan van de Ven wrote: On 7/11/2015 10:59 AM, Larry Finger wrote: On a Winbook TW100 BayTrail tablet, kernel 4.0 and later do not create /dev/rtc0 when CONFIG_PINCTRL_BAYTRAIL is set in the configuration. Removing this option from the config creates a real-time clock

Re: V4.0.x fails to create /dev/rtc0 on Winbook TW100 when CONFIG_PINCTRL_BAYTRAIL is set, bisected to commit 7486341

On 7/11/2015 10:59 AM, Larry Finger wrote: On a Winbook TW100 BayTrail tablet, kernel 4.0 and later do not create /dev/rtc0 when CONFIG_PINCTRL_BAYTRAIL is set in the configuration. Removing this option from the config creates a real-time clock; however, it is no longer possible to get the

Re: V4.0.x fails to create /dev/rtc0 on Winbook TW100 when CONFIG_PINCTRL_BAYTRAIL is set, bisected to commit 7486341

On 7/11/2015 11:26 AM, Porteus Kiosk wrote: Hello Arjan, We need it for setting up the time in the hardware clock through the 'hwclock' command. Thank you. hmm thinking about it after coffee... there is an RTC that can be exposed to userspace. hrmpf. Wonder why its not there for you

Re: [PATCH v3] x86/kconfig/32: Rename CONFIG_VM86 and default it to n

On 7/10/2015 8:34 AM, Andy Lutomirski wrote: VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is for now we can at least express the NOHZ_FULL thing in KConfig space... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH v3] x86/kconfig/32: Rename CONFIG_VM86 and default it to n

On 7/10/2015 8:34 AM, Andy Lutomirski wrote: VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is for now we can at least express the NOHZ_FULL thing in KConfig space... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to

Re: [PATCH] x86/kconfig/32: Make CONFIG_VM86 default to n and remove EXPERT

On 7/9/2015 11:40 AM, Andy Lutomirski wrote: VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is in use. The code is a big undocumented mess, it's a real PITA to test, and it looks like a big chunk of vm86_32.c is dead code. It also plays awful games with the entry asm. No

Re: [PATCH] x86/kconfig/32: Make CONFIG_VM86 default to n and remove EXPERT

On 7/9/2015 11:40 AM, Andy Lutomirski wrote: VM86 is entirely broken if ptrace, syscall auditing, or NOHZ_FULL is in use. The code is a big undocumented mess, it's a real PITA to test, and it looks like a big chunk of vm86_32.c is dead code. It also plays awful games with the entry asm. No

<    1   2   3   4   5   6   7   8   9   10   >