On Sun, Nov 04, 2018 at 10:54:56AM -0500, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck
>
> Add a driver for the Arcx anybus bridge.
>
> This chip embeds up to two Anybus-S application connectors
> (slots), and connects to the SoC via a parallel memory bus.
> There is also a CAN power
On Sun, Nov 04, 2018 at 10:54:56AM -0500, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck
>
> Add a driver for the Arcx anybus bridge.
>
> This chip embeds up to two Anybus-S application connectors
> (slots), and connects to the SoC via a parallel memory bus.
> There is also a CAN power
On 11/5/18 8:55 AM, Daniel Jordan wrote:
> Motivates and explains the ktask API for kernel clients.
>
> Signed-off-by: Daniel Jordan
> ---
> Documentation/core-api/index.rst | 1 +
> Documentation/core-api/ktask.rst | 213 +++
> 2 files changed, 214 insertions(+)
>
On 11/5/18 8:55 AM, Daniel Jordan wrote:
> Motivates and explains the ktask API for kernel clients.
>
> Signed-off-by: Daniel Jordan
> ---
> Documentation/core-api/index.rst | 1 +
> Documentation/core-api/ktask.rst | 213 +++
> 2 files changed, 214 insertions(+)
>
On Mon, Nov 05, 2018 at 06:11:52PM +0200, Tomer Maimon wrote:
> Modify Nuvoton watchdog Kconfig default supported architecture
> name to ARCH_NPCM7XX because ARCH_NPCM750 architecture name
> is not supported.
>
> Signed-off-by: Tomer Maimon
Reviewed-by: Guenter Roeck
> ---
>
This patch introduces a new iterator for_each_free_mem_pfn_range_in_zone.
This iterator will take care of making sure a given memory range provided
is in fact contained within a zone. It takes are of all the bounds checking
we were doing in deferred_grow_zone, and deferred_init_memmap. In
On Mon, Nov 05, 2018 at 06:11:52PM +0200, Tomer Maimon wrote:
> Modify Nuvoton watchdog Kconfig default supported architecture
> name to ARCH_NPCM7XX because ARCH_NPCM750 architecture name
> is not supported.
>
> Signed-off-by: Tomer Maimon
Reviewed-by: Guenter Roeck
> ---
>
This patch introduces a new iterator for_each_free_mem_pfn_range_in_zone.
This iterator will take care of making sure a given memory range provided
is in fact contained within a zone. It takes are of all the bounds checking
we were doing in deferred_grow_zone, and deferred_init_memmap. In
On Mon, Nov 05, 2018 at 04:13:56PM -0300, Arnaldo Carvalho de Melo wrote:
>
> I did the tests and it seems to work, its the same method used by the
> kernel sources, so I have this in place now:
>
> commit e2c39f36c354a06c6e9d32d4fdf8660b41803d82
> Author: Arnaldo Carvalho de Melo
> Date: Mon
On Mon, Nov 05, 2018 at 04:13:56PM -0300, Arnaldo Carvalho de Melo wrote:
>
> I did the tests and it seems to work, its the same method used by the
> kernel sources, so I have this in place now:
>
> commit e2c39f36c354a06c6e9d32d4fdf8660b41803d82
> Author: Arnaldo Carvalho de Melo
> Date: Mon
On 11/5/18, Andy Shevchenko wrote:
> On Mon, Nov 5, 2018 at 7:19 PM Pierre-Louis Bossart
> wrote:
>>
>>
>> >>> We have this ("strange") lines over the drivers:
>> >>>
>> >>> config BAR
>> >>> depends on FOO || FOO=n
>> >>>
>> >>> which guarantees that FOO will be not module when BAR is built-in.
On 11/5/18, Andy Shevchenko wrote:
> On Mon, Nov 5, 2018 at 7:19 PM Pierre-Louis Bossart
> wrote:
>>
>>
>> >>> We have this ("strange") lines over the drivers:
>> >>>
>> >>> config BAR
>> >>> depends on FOO || FOO=n
>> >>>
>> >>> which guarantees that FOO will be not module when BAR is built-in.
On Mon, Nov 05, 2018 at 12:18:33PM -0800, Andrew Morton wrote:
> > +++ b/mm/mmu_notifier.c
>
> But as it has no callers, why retain it?
... and this patch missed the declaration of mmu_notifier_synchronize
in include/linux/mmu_notifier.h (whether we delete it or rename it,
that mention of it
On Mon, Nov 05, 2018 at 12:18:33PM -0800, Andrew Morton wrote:
> > +++ b/mm/mmu_notifier.c
>
> But as it has no callers, why retain it?
... and this patch missed the declaration of mmu_notifier_synchronize
in include/linux/mmu_notifier.h (whether we delete it or rename it,
that mention of it
On Mon, 5 Nov 2018 12:40:00 -0800 Bart Van Assche wrote:
> This patch suppresses the following sparse warning:
>
> ./include/linux/slab.h:332:43: warning: dubious: x & !y
>
> ...
>
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -329,7 +329,7 @@ static __always_inline enum
On Mon, 5 Nov 2018 12:40:00 -0800 Bart Van Assche wrote:
> This patch suppresses the following sparse warning:
>
> ./include/linux/slab.h:332:43: warning: dubious: x & !y
>
> ...
>
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -329,7 +329,7 @@ static __always_inline enum
This patch is meant to try and consolidate all of the locking and unlocking
of both the parent and device when attaching or removing a driver from a
given device.
To do that I first consolidated the lock pattern into two functions
__device_driver_lock and __device_driver_unlock. After doing that
This patch moves the async_synchronize_full call out of
__device_release_driver and into driver_detach.
The idea behind this is that the async_synchronize_full call will only
guarantee that any existing async operations are flushed. This doesn't do
anything to guarantee that a hotplug event that
This patch is meant to try and consolidate all of the locking and unlocking
of both the parent and device when attaching or removing a driver from a
given device.
To do that I first consolidated the lock pattern into two functions
__device_driver_lock and __device_driver_unlock. After doing that
This patch moves the async_synchronize_full call out of
__device_release_driver and into driver_detach.
The idea behind this is that the async_synchronize_full call will only
guarantee that any existing async operations are flushed. This doesn't do
anything to guarantee that a hotplug event that
Hi,
On Mon, Nov 5, 2018 at 12:37 PM Rob Herring wrote:
>
> On Thu, Nov 01, 2018 at 01:29:54PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Nov 1, 2018 at 5:07 AM Veerabhadrarao Badiganti
> > wrote:
> > >
> > > For SDM845 SOC, new compatible string "qcom,sdm845-sdhci" is added.
> > >
> >
This patch introduces four new variants of the async_schedule_ functions
that allow scheduling on a specific NUMA node.
The first two functions are async_schedule_near and
async_schedule_near_domain which end up mapping to async_schedule and
async_schedule_domain but provide NUMA node specific
Hi,
On Mon, Nov 5, 2018 at 12:37 PM Rob Herring wrote:
>
> On Thu, Nov 01, 2018 at 01:29:54PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Nov 1, 2018 at 5:07 AM Veerabhadrarao Badiganti
> > wrote:
> > >
> > > For SDM845 SOC, new compatible string "qcom,sdm845-sdhci" is added.
> > >
> >
This patch introduces four new variants of the async_schedule_ functions
that allow scheduling on a specific NUMA node.
The first two functions are async_schedule_near and
async_schedule_near_domain which end up mapping to async_schedule and
async_schedule_domain but provide NUMA node specific
As per upstream discussion [1], we should have an SoC-specific
compatible string for Qualcomm's SDHCI nodes. Let's add it.
[1] https://lkml.kernel.org/r/20181105203657.GA32282@bogus
Signed-off-by: Douglas Anderson
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++--
As per upstream discussion [1], we should have an SoC-specific
compatible string for Qualcomm's SDHCI nodes. Let's add it.
[1] https://lkml.kernel.org/r/20181105203657.GA32282@bogus
Signed-off-by: Douglas Anderson
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 4 ++--
As per upstream discussion [1], we should have an SoC-specific
compatible string for Qualcomm's SDHCI nodes. Let's add it.
[1] https://lkml.kernel.org/r/20181105203657.GA32282@bogus
Signed-off-by: Douglas Anderson
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 4 ++--
As per upstream discussion [1], we should have an SoC-specific
compatible string for Qualcomm's SDHCI nodes. Let's add it.
[1] https://lkml.kernel.org/r/20181105203657.GA32282@bogus
Signed-off-by: Douglas Anderson
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 4 ++--
On 03-Nov-18 12:02 AM, Andy Shevchenko wrote:
On Fri, Nov 2, 2018 at 12:37 PM Rajneesh Bhardwaj
wrote:
The LTR values follow PCIE LTR encoding format and can be decoded as per
https://pcisig.com/sites/default/files/specification_documents/ECN_LatencyTolnReporting_14Aug08.pdf
This adds
On 5 November 2018 at 21:51, Florian Fainelli wrote:
> On 11/5/18 12:44 PM, Ard Biesheuvel wrote:
>> On 5 November 2018 at 21:41, Florian Fainelli wrote:
>>> On 11/5/18 12:39 PM, Ard Biesheuvel wrote:
Hi Florian,
On 31 October 2018 at 20:28, Florian Fainelli wrote:
> ARM64 is
On 03-Nov-18 12:02 AM, Andy Shevchenko wrote:
On Fri, Nov 2, 2018 at 12:37 PM Rajneesh Bhardwaj
wrote:
The LTR values follow PCIE LTR encoding format and can be decoded as per
https://pcisig.com/sites/default/files/specification_documents/ECN_LatencyTolnReporting_14Aug08.pdf
This adds
On 5 November 2018 at 21:51, Florian Fainelli wrote:
> On 11/5/18 12:44 PM, Ard Biesheuvel wrote:
>> On 5 November 2018 at 21:41, Florian Fainelli wrote:
>>> On 11/5/18 12:39 PM, Ard Biesheuvel wrote:
Hi Florian,
On 31 October 2018 at 20:28, Florian Fainelli wrote:
> ARM64 is
Thanks again for your time. My response inline.
On 02-Nov-18 11:57 PM, Andy Shevchenko wrote:
On Fri, Nov 2, 2018 at 12:29 PM Rajneesh Bhardwaj
wrote:
This adds support to show the Latency Tolerance Reporting for the IPs on
the PCH as reported by the PMC. The format shown here is raw LTR
Thanks again for your time. My response inline.
On 02-Nov-18 11:57 PM, Andy Shevchenko wrote:
On Fri, Nov 2, 2018 at 12:29 PM Rajneesh Bhardwaj
wrote:
This adds support to show the Latency Tolerance Reporting for the IPs on
the PCH as reported by the PMC. The format shown here is raw LTR
On 11/5/18, David Abdurachmanov wrote:
> Marcin Juszkiewicz reported issues while generating syscall table for riscv
> using 4.20-rc1. The patch refactors our unistd.h files to match some other
> architectures.
>
> - Add asm/unistd.h UAPI header, which has __ARCH_WANT_NEW_STAT
> - Remove
On 11/5/18, David Abdurachmanov wrote:
> Marcin Juszkiewicz reported issues while generating syscall table for riscv
> using 4.20-rc1. The patch refactors our unistd.h files to match some other
> architectures.
>
> - Add asm/unistd.h UAPI header, which has __ARCH_WANT_NEW_STAT
> - Remove
On 11/5/18 8:55 AM, Daniel Jordan wrote:
> diff --git a/init/Kconfig b/init/Kconfig
> index 41583f468cb4..ed82f76ed0b7 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -346,6 +346,17 @@ config AUDIT_TREE
> depends on AUDITSYSCALL
> select FSNOTIFY
>
> +config KTASK
> + bool
On 11/5/18 8:55 AM, Daniel Jordan wrote:
> diff --git a/init/Kconfig b/init/Kconfig
> index 41583f468cb4..ed82f76ed0b7 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -346,6 +346,17 @@ config AUDIT_TREE
> depends on AUDITSYSCALL
> select FSNOTIFY
>
> +config KTASK
> + bool
On Fri, Nov 02, 2018 at 06:56:50PM +0100, Milian Wolff wrote:
SNIP
> > >
> > > Note how precise levels 0 and 1 do not produce any samples where unwinding
> > > fails. But precise level 2 produces some, and precise level 3 increases
> > > the
> > > amount (by ca. ~2x).
> > >
> > > I can
On Fri, Nov 02, 2018 at 06:56:50PM +0100, Milian Wolff wrote:
SNIP
> > >
> > > Note how precise levels 0 and 1 do not produce any samples where unwinding
> > > fails. But precise level 2 produces some, and precise level 3 increases
> > > the
> > > amount (by ca. ~2x).
> > >
> > > I can
On Mon, Nov 05, 2018 at 12:18:33PM -0800, Andrew Morton wrote:
> On Mon, 5 Nov 2018 11:29:55 -0800 Sean Christopherson
> wrote:
>
> > ...and update its comment to explicitly reference its association with
> > mmu_notifier_call_srcu().
> >
> > Contrary to its name, mmu_notifier_synchronize()
On Mon, Nov 05, 2018 at 12:18:33PM -0800, Andrew Morton wrote:
> On Mon, 5 Nov 2018 11:29:55 -0800 Sean Christopherson
> wrote:
>
> > ...and update its comment to explicitly reference its association with
> > mmu_notifier_call_srcu().
> >
> > Contrary to its name, mmu_notifier_synchronize()
On Mon, Nov 5, 2018 at 7:19 PM Pierre-Louis Bossart
wrote:
>
>
> >>> We have this ("strange") lines over the drivers:
> >>>
> >>> config BAR
> >>> depends on FOO || FOO=n
> >>>
> >>> which guarantees that FOO will be not module when BAR is built-in.
> >> That's what I normally use, but I could
On Mon, Nov 5, 2018 at 7:19 PM Pierre-Louis Bossart
wrote:
>
>
> >>> We have this ("strange") lines over the drivers:
> >>>
> >>> config BAR
> >>> depends on FOO || FOO=n
> >>>
> >>> which guarantees that FOO will be not module when BAR is built-in.
> >> That's what I normally use, but I could
On Sun, 4 Nov 2018 10:54:58 -0500, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck
>
> This patch adds devicetree binding documentation for the
> Arcx anybus bridge.
>
> Signed-off-by: Sven Van Asbroeck
> ---
> .../bindings/misc/arcx,anybus-bridge.txt | 34 +++
> 1
On Sun, 4 Nov 2018 10:54:58 -0500, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck
>
> This patch adds devicetree binding documentation for the
> Arcx anybus bridge.
>
> Signed-off-by: Sven Van Asbroeck
> ---
> .../bindings/misc/arcx,anybus-bridge.txt | 34 +++
> 1
On 5 November 2018 at 21:41, Florian Fainelli wrote:
> On 11/5/18 12:39 PM, Ard Biesheuvel wrote:
>> Hi Florian,
>>
>> On 31 October 2018 at 20:28, Florian Fainelli wrote:
>>> ARM64 is the only architecture that re-defines
>>> __early_init_dt_declare_initrd() in order for that function to
On 5 November 2018 at 21:41, Florian Fainelli wrote:
> On 11/5/18 12:39 PM, Ard Biesheuvel wrote:
>> Hi Florian,
>>
>> On 31 October 2018 at 20:28, Florian Fainelli wrote:
>>> ARM64 is the only architecture that re-defines
>>> __early_init_dt_declare_initrd() in order for that function to
On Sun, 4 Nov 2018 10:54:57 -0500, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck
>
> arcx Inc. is an engineering company which provides advanced
> embedded systems and consulting services.
>
> Archronix is a technology design and product engineering firm
> specializing in hardware
On Sun, 4 Nov 2018 10:54:57 -0500, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck
>
> arcx Inc. is an engineering company which provides advanced
> embedded systems and consulting services.
>
> Archronix is a technology design and product engineering firm
> specializing in hardware
On Mon, Nov 05, 2018 at 12:38:05PM -0800, Olof Johansson wrote:
> Yeah, that's the way we've been trying to do for various subsystems
> and it's been working pretty well. Of course, if there's need to
> coordinate more closely for something in the future we'll be happy to
> do so.
Goodie. Let's
On Mon, Nov 05, 2018 at 12:38:05PM -0800, Olof Johansson wrote:
> Yeah, that's the way we've been trying to do for various subsystems
> and it's been working pretty well. Of course, if there's need to
> coordinate more closely for something in the future we'll be happy to
> do so.
Goodie. Let's
On Fri Oct 19 18, Stefan Berger wrote:
Extend the documentation for trusted keys with documentation for how to
set up a key for a TPM 2.0 so it can be used with a TPM 2.0 as well.
Signed-off-by: Stefan Berger
Reviewed-by: Mimi Zohar
---
.../security/keys/trusted-encrypted.rst | 31
On Fri Oct 19 18, Stefan Berger wrote:
Extend the documentation for trusted keys with documentation for how to
set up a key for a TPM 2.0 so it can be used with a TPM 2.0 as well.
Signed-off-by: Stefan Berger
Reviewed-by: Mimi Zohar
---
.../security/keys/trusted-encrypted.rst | 31
On Mon, Nov 5, 2018 at 7:30 PM Jarkko Sakkinen
wrote:
>
> On Sat, Nov 03, 2018 at 03:17:35PM +0200, Andy Shevchenko wrote:
> > On Sat, Nov 3, 2018 at 1:18 AM Jarkko Sakkinen
> > wrote:
> > >
> > > ENCLS is an umbrella instruction for a variety of cpl0 SGX functions.
> > > The ENCLS function that
On Mon, Nov 5, 2018 at 7:30 PM Jarkko Sakkinen
wrote:
>
> On Sat, Nov 03, 2018 at 03:17:35PM +0200, Andy Shevchenko wrote:
> > On Sat, Nov 3, 2018 at 1:18 AM Jarkko Sakkinen
> > wrote:
> > >
> > > ENCLS is an umbrella instruction for a variety of cpl0 SGX functions.
> > > The ENCLS function that
This patch suppresses the following sparse warning:
./include/linux/slab.h:332:43: warning: dubious: x & !y
Fixes: 1291523f2c1d ("mm, slab/slub: introduce kmalloc-reclaimable caches")
Cc: Vlastimil Babka
Cc: Mel Gorman
Cc: Christoph Lameter
Cc: Roman Gushchin
Signed-off-by: Bart Van Assche
This patch suppresses the following sparse warning:
./include/linux/slab.h:332:43: warning: dubious: x & !y
Fixes: 1291523f2c1d ("mm, slab/slub: introduce kmalloc-reclaimable caches")
Cc: Vlastimil Babka
Cc: Mel Gorman
Cc: Christoph Lameter
Cc: Roman Gushchin
Signed-off-by: Bart Van Assche
In two of the gen5 socfpga devicetree files, there are some lines
indented using spaces instead of tabs.
Fix this by correctly indenting them with tabs.
Signed-off-by: Simon Goldschmidt
---
arch/arm/boot/dts/socfpga.dtsi | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 4
In two of the gen5 socfpga devicetree files, there are some lines
indented using spaces instead of tabs.
Fix this by correctly indenting them with tabs.
Signed-off-by: Simon Goldschmidt
---
arch/arm/boot/dts/socfpga.dtsi | 2 +-
arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 4
On Mon, 29 Oct 2018 09:55:23 -0700, Florian Fainelli
wrote:
> All boards replicate the aliases node, move the aliases node to
> bcm-nsp.dtsi and add all the serial and ethernet ports such that a boot
> program like u-boot can populate MAC addresses accordingly.
>
> Signed-off-by: Florian
On Mon, Nov 5, 2018 at 11:47 AM Borislav Petkov wrote:
>
> Hi Olof,
>
> On Mon, Nov 05, 2018 at 06:51:26AM -0800, Olof Johansson wrote:
> > In general, for new functionality where needing both the driver change
> > and a DT change to enable it (or a driver change and a config change
> > to enable
On Mon, 29 Oct 2018 09:55:23 -0700, Florian Fainelli
wrote:
> All boards replicate the aliases node, move the aliases node to
> bcm-nsp.dtsi and add all the serial and ethernet ports such that a boot
> program like u-boot can populate MAC addresses accordingly.
>
> Signed-off-by: Florian
On Mon, Nov 5, 2018 at 11:47 AM Borislav Petkov wrote:
>
> Hi Olof,
>
> On Mon, Nov 05, 2018 at 06:51:26AM -0800, Olof Johansson wrote:
> > In general, for new functionality where needing both the driver change
> > and a DT change to enable it (or a driver change and a config change
> > to enable
On Thu, Nov 01, 2018 at 01:29:54PM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Nov 1, 2018 at 5:07 AM Veerabhadrarao Badiganti
> wrote:
> >
> > For SDM845 SOC, new compatible string "qcom,sdm845-sdhci" is added.
> >
> > Signed-off-by: Veerabhadrarao Badiganti
> > ---
> >
On Thu, Nov 01, 2018 at 01:29:54PM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Nov 1, 2018 at 5:07 AM Veerabhadrarao Badiganti
> wrote:
> >
> > For SDM845 SOC, new compatible string "qcom,sdm845-sdhci" is added.
> >
> > Signed-off-by: Veerabhadrarao Badiganti
> > ---
> >
On Sun, Nov 04, 2018 at 04:50:39PM -0800, David Miller wrote:
> From: Jiri Olsa
> Date: Sun, 4 Nov 2018 21:18:21 +0100
>
> > do you have some code I could check on?
>
> All I have is this patch which parallelizes the mmap readers in perf
> top.
I put something together.. still testing, but
On Sun, Nov 04, 2018 at 04:50:39PM -0800, David Miller wrote:
> From: Jiri Olsa
> Date: Sun, 4 Nov 2018 21:18:21 +0100
>
> > do you have some code I could check on?
>
> All I have is this patch which parallelizes the mmap readers in perf
> top.
I put something together.. still testing, but
Em Mon, Nov 05, 2018 at 07:53:17PM +, Hunter, Adrian escreveu:
> > -Original Message-
> > From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org]
> > Sent: Monday, November 5, 2018 9:36 PM
> > To: Hunter, Adrian
> > Cc: Jiri Olsa ; Andi Kleen ; linux-
> > ker...@vger.kernel.org;
Em Mon, Nov 05, 2018 at 07:53:17PM +, Hunter, Adrian escreveu:
> > -Original Message-
> > From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org]
> > Sent: Monday, November 5, 2018 9:36 PM
> > To: Hunter, Adrian
> > Cc: Jiri Olsa ; Andi Kleen ; linux-
> > ker...@vger.kernel.org;
On 11/5/18 2:27 PM, Simon Goldschmidt wrote:
> Follow the recent trend for the license description.
>
> This is also in an effort to fully sync the devicetrees with U-Boot.
>
> Signed-off-by: Simon Goldschmidt
> ---
> Resending this as requested by Dinh. It still applies on top of
> 4.20-rc1
On 11/5/18 2:27 PM, Simon Goldschmidt wrote:
> Follow the recent trend for the license description.
>
> This is also in an effort to fully sync the devicetrees with U-Boot.
>
> Signed-off-by: Simon Goldschmidt
> ---
> Resending this as requested by Dinh. It still applies on top of
> 4.20-rc1
On Mon, 5 Nov 2018, Andy Lutomirski wrote:
> On Mon, Nov 5, 2018 at 11:25 AM Nadav Amit wrote:
> Linus, hpa, or Dave, a question for you: suppose I map some page
> writably, write to it, then upgrade permissions to allow execute.
> Must I force all CPUs that might execute from it without first
>
On Mon, 5 Nov 2018, Andy Lutomirski wrote:
> On Mon, Nov 5, 2018 at 11:25 AM Nadav Amit wrote:
> Linus, hpa, or Dave, a question for you: suppose I map some page
> writably, write to it, then upgrade permissions to allow execute.
> Must I force all CPUs that might execute from it without first
>
Follow the recent trend for the license description.
This is also in an effort to fully sync the devicetrees with U-Boot.
Signed-off-by: Simon Goldschmidt
---
Resending this as requested by Dinh. It still applies on top of
4.20-rc1 as it only touches the file headers and nothing has changed
Follow the recent trend for the license description.
This is also in an effort to fully sync the devicetrees with U-Boot.
Signed-off-by: Simon Goldschmidt
---
Resending this as requested by Dinh. It still applies on top of
4.20-rc1 as it only touches the file headers and nothing has changed
Commit-ID: 63ecd3b13d5cf07959a2315ec62a7c62e20df114
Gitweb: https://git.kernel.org/tip/63ecd3b13d5cf07959a2315ec62a7c62e20df114
Author: Borislav Petkov
AuthorDate: Thu, 1 Nov 2018 16:24:43 +0100
Committer: Borislav Petkov
CommitDate: Mon, 5 Nov 2018 21:18:31 +0100
x86/gart: Rewrite
Commit-ID: 63ecd3b13d5cf07959a2315ec62a7c62e20df114
Gitweb: https://git.kernel.org/tip/63ecd3b13d5cf07959a2315ec62a7c62e20df114
Author: Borislav Petkov
AuthorDate: Thu, 1 Nov 2018 16:24:43 +0100
Committer: Borislav Petkov
CommitDate: Mon, 5 Nov 2018 21:18:31 +0100
x86/gart: Rewrite
On Mon, Nov 05, 2018 at 04:35:40PM +0100, Ingo Molnar wrote:
> s/shutdown
> /shut down
Fixed.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Mon, Nov 05, 2018 at 04:35:40PM +0100, Ingo Molnar wrote:
> s/shutdown
> /shut down
Fixed.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Commit-ID: 43500e6f294d175602606c77bfb0d8cd4ea88b4f
Gitweb: https://git.kernel.org/tip/43500e6f294d175602606c77bfb0d8cd4ea88b4f
Author: Sean Christopherson
AuthorDate: Mon, 5 Nov 2018 10:57:25 -0800
Committer: Borislav Petkov
CommitDate: Mon, 5 Nov 2018 20:54:20 +0100
x86/cpufeatures:
Commit-ID: 43500e6f294d175602606c77bfb0d8cd4ea88b4f
Gitweb: https://git.kernel.org/tip/43500e6f294d175602606c77bfb0d8cd4ea88b4f
Author: Sean Christopherson
AuthorDate: Mon, 5 Nov 2018 10:57:25 -0800
Committer: Borislav Petkov
CommitDate: Mon, 5 Nov 2018 20:54:20 +0100
x86/cpufeatures:
Add schedstats to measure the effectiveness of searching for idle CPUs
and stealing tasks. This is a temporary patch intended for use during
development only. SCHEDSTAT_VERSION is bumped to 16, and the following
fields are added to the per-CPU statistics of /proc/schedstat:
field 10: # of times
On 11/5/18 10:35 AM, Linus Torvalds wrote:
On Mon, Nov 5, 2018 at 10:28 AM Yang Shi wrote:
Actually, the commit is mainly for optimizing the long stall time caused
by holding mmap_sem by write when unmapping or shrinking large mapping.
It downgrades write mmap_sem to read when zapping
Add schedstats to measure the effectiveness of searching for idle CPUs
and stealing tasks. This is a temporary patch intended for use during
development only. SCHEDSTAT_VERSION is bumped to 16, and the following
fields are added to the per-CPU statistics of /proc/schedstat:
field 10: # of times
On 11/5/18 10:35 AM, Linus Torvalds wrote:
On Mon, Nov 5, 2018 at 10:28 AM Yang Shi wrote:
Actually, the commit is mainly for optimizing the long stall time caused
by holding mmap_sem by write when unmapping or shrinking large mapping.
It downgrades write mmap_sem to read when zapping
From: Steve Sistare
Provide struct sparsemask and functions to manipulate it. A sparsemask is
a sparse bitmap. It reduces cache contention vs the usual bitmap when many
threads concurrently set, clear, and visit elements, by reducing the number
of significant bits per cacheline. For each 64
The STEAL feature causes regressions on hackbench on larger NUMA systems,
so disable it on systems with more than sched_steal_node_limit nodes
(default 2). Note that the feature remains enabled as seen in features.h
and /sys/kernel/debug/sched_features, but stealing is only performed if
nodes <=
The detach_task function takes a struct lb_env argument, but only needs a
few of its members. Pass the rq and cpu arguments explicitly so the
function may be called from code that is not based on lb_env. No
functional change.
Signed-off-by: Steve Sistare
---
kernel/sched/fair.c | 14
On Mon, 5 Nov 2018 11:29:55 -0800 Sean Christopherson
wrote:
> ...and update its comment to explicitly reference its association with
> mmu_notifier_call_srcu().
>
> Contrary to its name, mmu_notifier_synchronize() does not synchronize
> the notifier's SRCU instance, but rather waits for RCU
From: Steve Sistare
Provide struct sparsemask and functions to manipulate it. A sparsemask is
a sparse bitmap. It reduces cache contention vs the usual bitmap when many
threads concurrently set, clear, and visit elements, by reducing the number
of significant bits per cacheline. For each 64
The STEAL feature causes regressions on hackbench on larger NUMA systems,
so disable it on systems with more than sched_steal_node_limit nodes
(default 2). Note that the feature remains enabled as seen in features.h
and /sys/kernel/debug/sched_features, but stealing is only performed if
nodes <=
The detach_task function takes a struct lb_env argument, but only needs a
few of its members. Pass the rq and cpu arguments explicitly so the
function may be called from code that is not based on lb_env. No
functional change.
Signed-off-by: Steve Sistare
---
kernel/sched/fair.c | 14
On Mon, 5 Nov 2018 11:29:55 -0800 Sean Christopherson
wrote:
> ...and update its comment to explicitly reference its association with
> mmu_notifier_call_srcu().
>
> Contrary to its name, mmu_notifier_synchronize() does not synchronize
> the notifier's SRCU instance, but rather waits for RCU
From: Steve Sistare
Define and initialize a sparse bitmap of overloaded CPUs, per
last-level-cache scheduling domain, for use by the CFS scheduling class.
Save a pointer to cfs_overload_cpus in the rq for efficient access.
Signed-off-by: Steve Sistare
---
include/linux/sched/topology.h | 1 +
From: Steve Sistare
Define and initialize a sparse bitmap of overloaded CPUs, per
last-level-cache scheduling domain, for use by the CFS scheduling class.
Save a pointer to cfs_overload_cpus in the rq for efficient access.
Signed-off-by: Steve Sistare
---
include/linux/sched/topology.h | 1 +
An overloaded CPU has more than 1 runnable task. When a CFS task wakes
on a CPU, if h_nr_running transitions from 1 to more, then set the CPU in
the cfs_overload_cpus bitmap. When a CFS task sleeps, if h_nr_running
transitions from 2 to less, then clear the CPU in cfs_overload_cpus.
When a CPU has no more CFS tasks to run, and idle_balance() fails to find a
task, then attempt to steal a task from an overloaded CPU in the same LLC,
using the cfs_overload_cpus bitmap to efficiently identify candidates. To
minimize search time, steal the first migratable task that is found when
An overloaded CPU has more than 1 runnable task. When a CFS task wakes
on a CPU, if h_nr_running transitions from 1 to more, then set the CPU in
the cfs_overload_cpus bitmap. When a CFS task sleeps, if h_nr_running
transitions from 2 to less, then clear the CPU in cfs_overload_cpus.
When a CPU has no more CFS tasks to run, and idle_balance() fails to find a
task, then attempt to steal a task from an overloaded CPU in the same LLC,
using the cfs_overload_cpus bitmap to efficiently identify candidates. To
minimize search time, steal the first migratable task that is found when
401 - 500 of 1452 matches
Mail list logo
