Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

On 2017-03-23 01:53, Michel Dänzer wrote: > From: Michel Dänzer > > Otherwise this can also prevent modesets e.g. for switching VTs, when > multiple monitors with different native resolutions are connected. When changing resolution a regular fbdev driver also changes

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

On 2017-03-23 01:53, Michel Dänzer wrote: > From: Michel Dänzer > > Otherwise this can also prevent modesets e.g. for switching VTs, when > multiple monitors with different native resolutions are connected. When changing resolution a regular fbdev driver also changes display timing accordingly

Re: [net-next PATCH v2 8/8] net: Introduce SO_INCOMING_NAPI_ID

On Thu, Mar 23, 2017 at 3:43 PM, Andy Lutomirski wrote: > On Thu, Mar 23, 2017 at 2:38 PM, Alexander Duyck > wrote: >> From: Sridhar Samudrala >> >> This socket option returns the NAPI ID associated with the queue on which

Re: [net-next PATCH v2 8/8] net: Introduce SO_INCOMING_NAPI_ID

On Thu, Mar 23, 2017 at 3:43 PM, Andy Lutomirski wrote: > On Thu, Mar 23, 2017 at 2:38 PM, Alexander Duyck > wrote: >> From: Sridhar Samudrala >> >> This socket option returns the NAPI ID associated with the queue on which >> the last frame is received. This information can be used by the apps

Re: [PATCH v3 2/9] bcache: Don't reinvent the wheel but use existing llist API

On Tue, Feb 14, 2017 at 04:26:23PM +0900, Byungchul Park wrote: > Although llist provides proper APIs, they are not used. Make them used. +cc ax...@fb.com > > Signed-off-by: Byungchul Park > --- > drivers/md/bcache/closure.c | 17 +++-- > 1 file changed, 3

Re: [PATCH v3 2/9] bcache: Don't reinvent the wheel but use existing llist API

On Tue, Feb 14, 2017 at 04:26:23PM +0900, Byungchul Park wrote: > Although llist provides proper APIs, they are not used. Make them used. +cc ax...@fb.com > > Signed-off-by: Byungchul Park > --- > drivers/md/bcache/closure.c | 17 +++-- > 1 file changed, 3 insertions(+), 14

Re: [BUG nohz]: wrong user and system time accounting

On Thu, 2017-03-23 at 16:55 -0400, Luiz Capitulino wrote: > When there are two or more tasks executing in user-space and > taking 100% of a nohz_full CPU, top reports 70% system time > and 30% user time utilization. Sometimes I'm even able to get > 100% system time and 0% user time. > > This was

Re: [BUG nohz]: wrong user and system time accounting

On Thu, 2017-03-23 at 16:55 -0400, Luiz Capitulino wrote: > When there are two or more tasks executing in user-space and > taking 100% of a nohz_full CPU, top reports 70% system time > and 30% user time utilization. Sometimes I'm even able to get > 100% system time and 0% user time. > > This was

[PATCH] x86/mce: Don't print all MCEs when mcelog is active

From: Andi Kleen Since cd9c57c x86/MCE: Dump MCE to dmesg if no consumers in 4.9 all MCEs are printed even when mcelog is running. This fixes this regression to not print again when mcelog is running, because it already takes care of the logging. This was hit by a lot of

[PATCH] x86/mce: Don't print all MCEs when mcelog is active

From: Andi Kleen Since cd9c57c x86/MCE: Dump MCE to dmesg if no consumers in 4.9 all MCEs are printed even when mcelog is running. This fixes this regression to not print again when mcelog is running, because it already takes care of the logging. This was hit by a lot of people, so it's good

Re: [PATCH 3/4] zram: implement deduplication in zram

On Thu, Mar 23, 2017 at 12:04:23PM +0900, Joonsoo Kim wrote: > On Wed, Mar 22, 2017 at 08:41:21AM +0900, Minchan Kim wrote: > > Hi Joonsoo, > > > > On Thu, Mar 16, 2017 at 11:46:37AM +0900, js1...@gmail.com wrote: > > > From: Joonsoo Kim > > > > > > This patch implements

Re: [PATCH 3/4] zram: implement deduplication in zram

On Thu, Mar 23, 2017 at 12:04:23PM +0900, Joonsoo Kim wrote: > On Wed, Mar 22, 2017 at 08:41:21AM +0900, Minchan Kim wrote: > > Hi Joonsoo, > > > > On Thu, Mar 16, 2017 at 11:46:37AM +0900, js1...@gmail.com wrote: > > > From: Joonsoo Kim > > > > > > This patch implements deduplication feature

Re: [PATCH 1/4] mm/zsmalloc: always set movable/highmem flag to the zspage

Hi Joonsoo, On Thu, Mar 23, 2017 at 11:10:23AM +0900, Joonsoo Kim wrote: > On Tue, Mar 21, 2017 at 08:10:05PM +0900, Minchan Kim wrote: > > Hi Joonsoo, > > > > On Thu, Mar 16, 2017 at 11:46:35AM +0900, js1...@gmail.com wrote: > > > From: Joonsoo Kim > > > > > > Zspage

Re: [PATCH 1/4] mm/zsmalloc: always set movable/highmem flag to the zspage

Hi Joonsoo, On Thu, Mar 23, 2017 at 11:10:23AM +0900, Joonsoo Kim wrote: > On Tue, Mar 21, 2017 at 08:10:05PM +0900, Minchan Kim wrote: > > Hi Joonsoo, > > > > On Thu, Mar 16, 2017 at 11:46:35AM +0900, js1...@gmail.com wrote: > > > From: Joonsoo Kim > > > > > > Zspage is always movable and is

[PATCH v4 2/2] drm/panel: add innolux,p079zca panel driver

Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI panel. Signed-off-by: Chris Zhong Reviewed-by: Sean Paul Tested-by: Brian Norris --- Changes in v4: - remove backlight check after probe - add bpc info

[PATCH v4 2/2] drm/panel: add innolux,p079zca panel driver

Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI panel. Signed-off-by: Chris Zhong Reviewed-by: Sean Paul Tested-by: Brian Norris --- Changes in v4: - remove backlight check after probe - add bpc info Changes in v3: - printk err after regulator_disable(innolux->supply)

[PATCH] perf, tools, script: Skip locking overhead in perf script

From: Andi Kleen I was tired of seeing ~10% locking overhead in perf script while doing larger PT decodes. perf script doesn't need any locking because it is single threaded. Nearly all of it comes from looking at the maps cache. I added a global variable to indicate perf

[PATCH] perf, tools, script: Skip locking overhead in perf script

From: Andi Kleen I was tired of seeing ~10% locking overhead in perf script while doing larger PT decodes. perf script doesn't need any locking because it is single threaded. Nearly all of it comes from looking at the maps cache. I added a global variable to indicate perf is running single

[PATCH v4 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings

The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and connected to DSI using four lanes. Signed-off-by: Chris Zhong Reviewed-by: Brian Norris --- Changes in v4: None Changes in v3: None Changes in v2: None

[PATCH 8/8] MAINTAINERS: Add file patterns for fpga device tree bindings

From: Geert Uytterhoeven Submitters of device tree binding documentation may forget to CC the subsystem maintainer if this is missing. Signed-off-by: Geert Uytterhoeven Acked-by: Moritz Fischer Cc: Alan Tull

Re: [PATCH v1 RESEND 1/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

Hi, Ping! Since our kaslr mm back port has been held to wait for this upstream fix, and post deadline is very close, can this patch be merged or picked up into tip-bot treeu? This is an obvious code bug, it has risk to cause kexec/kdump boot failure, and the current code change won't bring

[PATCH v4 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings

The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and connected to DSI using four lanes. Signed-off-by: Chris Zhong Reviewed-by: Brian Norris --- Changes in v4: None Changes in v3: None Changes in v2: None .../bindings/display/panel/innolux,p079zca.txt | 23

[PATCH 8/8] MAINTAINERS: Add file patterns for fpga device tree bindings

From: Geert Uytterhoeven Submitters of device tree binding documentation may forget to CC the subsystem maintainer if this is missing. Signed-off-by: Geert Uytterhoeven Acked-by: Moritz Fischer Cc: Alan Tull Cc: Moritz Fischer Cc: linux-f...@vger.kernel.org Acked-by: Alan Tull ---

Re: [PATCH v1 RESEND 1/2] x86/mm/KASLR: EFI region is mistakenly included into KASLR VA space for randomization

Hi, Ping! Since our kaslr mm back port has been held to wait for this upstream fix, and post deadline is very close, can this patch be merged or picked up into tip-bot treeu? This is an obvious code bug, it has risk to cause kexec/kdump boot failure, and the current code change won't bring

[PATCH 3/8] fpga manager: Add Xilinx slave serial SPI driver

From: Anatolij Gustschin The driver loads FPGA firmware over SPI, using the "slave serial" configuration interface on Xilinx FPGAs. Signed-off-by: Anatolij Gustschin Acked-by: Michal Simek Reviewed-by: Moritz Fischer

RE: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose dependency has not met

Hi Arnd > -Original Message- > From: linuxarm-boun...@huawei.com [mailto:linuxarm-boun...@huawei.com] > On Behalf Of Gabriele Paoloni > Sent: 16 March 2017 16:14 > To: Arnd Bergmann; Yuanzhichang > Cc: Mark Rutland; Benjamin Herrenschmidt; Rafael Wysocki; linux-pci; > Will Deacon;

[PATCH 1/8] fpga: altera_freeze_bridge: Constify ops

From: Moritz Fischer The ops are not changing, make them const. Signed-off-by: Moritz Fischer Cc: Alan Tull Cc: linux-kernel@vger.kernel.org Cc: linux-f...@vger.kernel.org Acked-by: Alan Tull ---

[PATCH 1/8] fpga: altera_freeze_bridge: Constify ops

From: Moritz Fischer The ops are not changing, make them const. Signed-off-by: Moritz Fischer Cc: Alan Tull Cc: linux-kernel@vger.kernel.org Cc: linux-f...@vger.kernel.org Acked-by: Alan Tull --- drivers/fpga/altera-freeze-bridge.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 3/8] fpga manager: Add Xilinx slave serial SPI driver

From: Anatolij Gustschin The driver loads FPGA firmware over SPI, using the "slave serial" configuration interface on Xilinx FPGAs. Signed-off-by: Anatolij Gustschin Acked-by: Michal Simek Reviewed-by: Moritz Fischer Acked-by: Alan Tull --- drivers/fpga/Kconfig | 7 ++

RE: [PATCH V7 5/7] ACPI: Delay the enumeration on the devices whose dependency has not met

Hi Arnd > -Original Message- > From: linuxarm-boun...@huawei.com [mailto:linuxarm-boun...@huawei.com] > On Behalf Of Gabriele Paoloni > Sent: 16 March 2017 16:14 > To: Arnd Bergmann; Yuanzhichang > Cc: Mark Rutland; Benjamin Herrenschmidt; Rafael Wysocki; linux-pci; > Will Deacon;

[PATCH 5/8] fpga pr ip: Core driver support for Altera Partial Reconfiguration IP.

From: Matthew Gerlach Adding the core functions necessary for a fpga-mgr driver for the Altera Partial IP component. It is intended for these functions to be used by the various bus implementations like the platform bus or the PCIe bus. Signed-off-by: Matthew

RE: [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Bernd Faust > Sent: Thursday, February 16, 2017 10:42 AM > To: Kirsher, Jeffrey T ; Lubetkin, YanirX > ; intel-wired-...@lists.osuosl.org; >

[PATCH 5/8] fpga pr ip: Core driver support for Altera Partial Reconfiguration IP.

From: Matthew Gerlach Adding the core functions necessary for a fpga-mgr driver for the Altera Partial IP component. It is intended for these functions to be used by the various bus implementations like the platform bus or the PCIe bus. Signed-off-by: Matthew Gerlach Acked-by: Alan Tull ---

RE: [PATCH] e1000e: fix timing for 82579 Gigabit Ethernet controller

> From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Bernd Faust > Sent: Thursday, February 16, 2017 10:42 AM > To: Kirsher, Jeffrey T ; Lubetkin, YanirX > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: Bernd

Re: linux-next: manual merge of the net-next tree with Linus' tree

From: Stephen Rothwell Date: Fri, 24 Mar 2017 11:05:14 +1100 > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > kernel/bpf/hashtab.c > > between commit: > > 8c290e60fa2a ("bpf: fix hashmap extra_elems logic") > > from Linus' tree

Re: linux-next: manual merge of the net-next tree with Linus' tree

From: Stephen Rothwell Date: Fri, 24 Mar 2017 11:05:14 +1100 > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > kernel/bpf/hashtab.c > > between commit: > > 8c290e60fa2a ("bpf: fix hashmap extra_elems logic") > > from Linus' tree and commit: > >

[PATCH v3] block: trace completion of all bios.

Currently only dm and md/raid5 bios trigger trace_block_bio_complete(). Now that we have bio_chain() and bio_inc_remaining(), it is not possible, in general, for a driver to know when the bio is really complete. Only bio_endio() knows that. So move the trace_block_bio_complete() call to

[PATCH v3] block: trace completion of all bios.

Currently only dm and md/raid5 bios trigger trace_block_bio_complete(). Now that we have bio_chain() and bio_inc_remaining(), it is not possible, in general, for a driver to know when the bio is really complete. Only bio_endio() knows that. So move the trace_block_bio_complete() call to

Re: [PATCH v2] block: trace completion of all bios.

On Thu, Mar 23 2017, Ming Lei wrote: > On Thu, Mar 23, 2017 at 05:29:02PM +1100, NeilBrown wrote: >> >> /** >> + * bio_endio_notrace - end I/O on a bio without tracing >> + * @bio:bio >> + * >> + * Description: >> + * bio_endio_notrace() will end I/O on the whole bio. >> + *

Re: [PATCH v2] block: trace completion of all bios.

On Thu, Mar 23 2017, Ming Lei wrote: > On Thu, Mar 23, 2017 at 05:29:02PM +1100, NeilBrown wrote: >> >> /** >> + * bio_endio_notrace - end I/O on a bio without tracing >> + * @bio:bio >> + * >> + * Description: >> + * bio_endio_notrace() will end I/O on the whole bio. >> + *

linux-next: manual merge of the net-next tree with Linus' tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: kernel/bpf/hashtab.c between commit: 8c290e60fa2a ("bpf: fix hashmap extra_elems logic") from Linus' tree and commit: bcc6b1b7ebf8 ("bpf: Add hash of maps support") from the net-next tree. I fixed it up (see

linux-next: manual merge of the net-next tree with Linus' tree

Hi all, Today's linux-next merge of the net-next tree got a conflict in: kernel/bpf/hashtab.c between commit: 8c290e60fa2a ("bpf: fix hashmap extra_elems logic") from Linus' tree and commit: bcc6b1b7ebf8 ("bpf: Add hash of maps support") from the net-next tree. I fixed it up (see

Re: [PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

From: Jie Deng Date: Thu, 23 Mar 2017 12:03:45 +0800 > The driver "dwc-xlgmac" is dual-licensed. This patch adds > declaration of dual license in file headers. > > Signed-off-by: Jie Deng Applied.

Re: [PATCH net-next 2/2] net: dwc-xlgmac: use dual license

From: Jie Deng Date: Thu, 23 Mar 2017 12:03:46 +0800 > The driver "dwc-xlgmac" is dual-licensed. > Declare the dual license with MODULE_LICENSE(). > > Signed-off-by: Jie Deng Applied.

Re: [PATCH net-next 1/2] net: dwc-xlgmac: declaration of dual license in headers

From: Jie Deng Date: Thu, 23 Mar 2017 12:03:45 +0800 > The driver "dwc-xlgmac" is dual-licensed. This patch adds > declaration of dual license in file headers. > > Signed-off-by: Jie Deng Applied.

Re: [PATCH net-next 2/2] net: dwc-xlgmac: use dual license

From: Jie Deng Date: Thu, 23 Mar 2017 12:03:46 +0800 > The driver "dwc-xlgmac" is dual-licensed. > Declare the dual license with MODULE_LICENSE(). > > Signed-off-by: Jie Deng Applied.

[PATCH] rtc: ds1307: support m41t0 variant

The m41t0 variant is very similar to the already supported m41t00 variant, with the notable exception of the oscillator fail bit. The data sheet notes: If the oscillator fail (OF) bit is internally set to a '1,' this indicates that the oscillator has either stopped, or was stopped for some

[PATCH] rtc: ds1307: support m41t0 variant

The m41t0 variant is very similar to the already supported m41t00 variant, with the notable exception of the oscillator fail bit. The data sheet notes: If the oscillator fail (OF) bit is internally set to a '1,' this indicates that the oscillator has either stopped, or was stopped for some

Re: [PATCH v4 1/2] dt: bindings: fpga: add xilinx slave-serial binding description

On Thu, Mar 16, 2017 at 6:01 AM, Michal Simek wrote: > On 28.2.2017 17:40, Anatolij Gustschin wrote: >> Add dt binding documentation details for Xilinx FPGA configuration >> over slave serial interface. >> >> Signed-off-by: Anatolij Gustschin >> Acked-by: Moritz

Re: [PATCH v4 1/2] dt: bindings: fpga: add xilinx slave-serial binding description

On Thu, Mar 16, 2017 at 6:01 AM, Michal Simek wrote: > On 28.2.2017 17:40, Anatolij Gustschin wrote: >> Add dt binding documentation details for Xilinx FPGA configuration >> over slave serial interface. >> >> Signed-off-by: Anatolij Gustschin >> Acked-by: Moritz Fischer >> Acked-by: Rob Herring

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

From: Bjorn Andersson Date: Wed, 22 Mar 2017 14:57:33 -0700 > On Wed 22 Mar 11:44 PDT 2017, David Miller wrote: > >> From: Bjorn Andersson >> Date: Mon, 20 Mar 2017 16:35:42 -0700 >> >> What is the status of the Kconfig dependency fix

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

From: Bjorn Andersson Date: Wed, 22 Mar 2017 14:57:33 -0700 > On Wed 22 Mar 11:44 PDT 2017, David Miller wrote: > >> From: Bjorn Andersson >> Date: Mon, 20 Mar 2017 16:35:42 -0700 >> >> What is the status of the Kconfig dependency fix and how will I be >> getting it? >> > > There are two

Re: [PATCH v3 02/12] irqchip: mtk-sysirq: extend intpol base to arbitrary number

On Thu, 2017-03-23 at 16:25 +, Marc Zyngier wrote: > On 19/03/17 15:26, Mars Cheng wrote: > > Originally driver only supports one base. However, MT6797 has > > more than one bases to configure interrupt polarity. To support > > possible design change, here comes a solution to use arbitrary > >

Re: [PATCH v3 02/12] irqchip: mtk-sysirq: extend intpol base to arbitrary number

On Thu, 2017-03-23 at 16:25 +, Marc Zyngier wrote: > On 19/03/17 15:26, Mars Cheng wrote: > > Originally driver only supports one base. However, MT6797 has > > more than one bases to configure interrupt polarity. To support > > possible design change, here comes a solution to use arbitrary > >

Re: [PATCH v4 2/2] fpga manager: Add Xilinx slave serial SPI driver

On Thu, Mar 16, 2017 at 9:58 AM, Moritz Fischer wrote: > On Tue, Feb 28, 2017 at 8:40 AM, Anatolij Gustschin wrote: >> The driver loads FPGA firmware over SPI, using the "slave serial" >> configuration interface on Xilinx FPGAs. >> >> Signed-off-by: Anatolij

Re: [PATCH v4 2/2] fpga manager: Add Xilinx slave serial SPI driver

On Thu, Mar 16, 2017 at 9:58 AM, Moritz Fischer wrote: > On Tue, Feb 28, 2017 at 8:40 AM, Anatolij Gustschin wrote: >> The driver loads FPGA firmware over SPI, using the "slave serial" >> configuration interface on Xilinx FPGAs. >> >> Signed-off-by: Anatolij Gustschin > Reviewed-by: Moritz

Re: [PATCH v3 00/12] Add Basic SoC support for MT6797

On Thu, 2017-03-23 at 15:24 +, Marc Zyngier wrote: > Hi Mars, > > On 23/03/17 00:46, Mars Cheng wrote: > > Hi Matthias, Rob, Marc, Stephen > > > > gentle ping for this patch set. > > I appreciate that you're eager to see this reviewed, but less than 4 > days between a posting and a reminder

Re: [PATCH v3 00/12] Add Basic SoC support for MT6797

On Thu, 2017-03-23 at 15:24 +, Marc Zyngier wrote: > Hi Mars, > > On 23/03/17 00:46, Mars Cheng wrote: > > Hi Matthias, Rob, Marc, Stephen > > > > gentle ping for this patch set. > > I appreciate that you're eager to see this reviewed, but less than 4 > days between a posting and a reminder

Re: [v1 0/5] parallelized "struct page" zeroing

On 03/23/2017 07:35 PM, David Miller wrote: From: Matthew Wilcox Date: Thu, 23 Mar 2017 16:26:38 -0700 On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: When deferred struct page initialization feature is enabled, we get a performance gain of initializing

Re: [v1 0/5] parallelized "struct page" zeroing

On 03/23/2017 07:35 PM, David Miller wrote: From: Matthew Wilcox Date: Thu, 23 Mar 2017 16:26:38 -0700 On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: When deferred struct page initialization feature is enabled, we get a performance gain of initializing vmemmap in parallel

Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

On 23/03/2017 18:03, Mason wrote: > The host bridge actually supports 256 MSIs. > > IIUC, what you suggested on IRC is that I support 256 in the driver, > and only read the status for *enabled* MSIs. > > Pseudo-code: > > for every 32-bit blob in the enabled bitmap > if the value is non-zero

Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

On 23/03/2017 18:03, Mason wrote: > The host bridge actually supports 256 MSIs. > > IIUC, what you suggested on IRC is that I support 256 in the driver, > and only read the status for *enabled* MSIs. > > Pseudo-code: > > for every 32-bit blob in the enabled bitmap > if the value is non-zero

Re: [v1 0/5] parallelized "struct page" zeroing

Hi Matthew, Thank you for your comment. If you look at the data, having memset() actually benefits initializing data. With base it takes: [ 66.148867] node 0 initialised, 128312523 pages in 7200ms With fix: [ 15.260634] node 0 initialised, 128312523 pages in 4190ms So 4.19s vs 7.2s for

Re: [v1 0/5] parallelized "struct page" zeroing

Hi Matthew, Thank you for your comment. If you look at the data, having memset() actually benefits initializing data. With base it takes: [ 66.148867] node 0 initialised, 128312523 pages in 7200ms With fix: [ 15.260634] node 0 initialised, 128312523 pages in 4190ms So 4.19s vs 7.2s for

Re: [v1 0/5] parallelized "struct page" zeroing

From: Matthew Wilcox Date: Thu, 23 Mar 2017 16:26:38 -0700 > On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: >> When deferred struct page initialization feature is enabled, we get a >> performance gain of initializing vmemmap in parallel after other CPUs are

Re: [v1 0/5] parallelized "struct page" zeroing

From: Matthew Wilcox Date: Thu, 23 Mar 2017 16:26:38 -0700 > On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: >> When deferred struct page initialization feature is enabled, we get a >> performance gain of initializing vmemmap in parallel after other CPUs are >> started. However,

Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

On Thu, Mar 23, 2017 at 10:54:53PM +0100, Linus Walleij wrote: > Hm, I certainly want it... but it would be unreasonable of me to expect > Eric to cold-code a big upfront design for systems he can't even test > this on. > > What I would request would rather be: please do not put in any >

Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

On Thu, Mar 23, 2017 at 10:54:53PM +0100, Linus Walleij wrote: > Hm, I certainly want it... but it would be unreasonable of me to expect > Eric to cold-code a big upfront design for systems he can't even test > this on. > > What I would request would rather be: please do not put in any >

Re: [v1 0/5] parallelized "struct page" zeroing

On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: > When deferred struct page initialization feature is enabled, we get a > performance gain of initializing vmemmap in parallel after other CPUs are > started. However, we still zero the memory for vmemmap using one boot CPU. > This

Re: [v1 0/5] parallelized "struct page" zeroing

On Thu, Mar 23, 2017 at 07:01:48PM -0400, Pavel Tatashin wrote: > When deferred struct page initialization feature is enabled, we get a > performance gain of initializing vmemmap in parallel after other CPUs are > started. However, we still zero the memory for vmemmap using one boot CPU. > This

Re: [PATCH] lib/syscall: Clear return values when no stack

On Thu, Mar 23, 2017 at 3:46 PM, Kees Cook wrote: > Commit aa1f1a639621 ("lib/syscall: Pin the task stack in collect_syscall()") > added logic to handle a process stack not existing, but left sp and pc > uninitialized, which can be later reported via /proc/$pid/syscall for

Re: [PATCH] lib/syscall: Clear return values when no stack

On Thu, Mar 23, 2017 at 3:46 PM, Kees Cook wrote: > Commit aa1f1a639621 ("lib/syscall: Pin the task stack in collect_syscall()") > added logic to handle a process stack not existing, but left sp and pc > uninitialized, which can be later reported via /proc/$pid/syscall for zombie > processes,

Re: [PATCH v2 2/2] of/pci: Fix memory leak in of_pci_get_host_bridge_resources

On Thu, Mar 23, 2017 at 3:07 PM, Rob Herring wrote: > On Thu, Mar 23, 2017 at 3:12 AM, Jeffy Chen wrote: >> Currently we only free the allocated resource struct when error. >> This would cause memory leak after pci_free_resource_list. >> >>

Re: [PATCH v2 2/2] of/pci: Fix memory leak in of_pci_get_host_bridge_resources

On Thu, Mar 23, 2017 at 3:07 PM, Rob Herring wrote: > On Thu, Mar 23, 2017 at 3:12 AM, Jeffy Chen wrote: >> Currently we only free the allocated resource struct when error. >> This would cause memory leak after pci_free_resource_list. >> >> Signed-off-by: Jeffy Chen >> --- >> >> Changes in v2:

Re: [RFC] Add option to mount only a pids subset

On Thu, Mar 23, 2017 at 05:05:07PM +0100, Oleg Nesterov wrote: > Again, I can't really review this, I know nothing about vfs, but since > nobody else replied... Thanks anyway :) > On 03/20, Alexey Gladkov wrote: > > > > @@ -97,7 +169,23 @@ static struct dentry *proc_mount(struct > >

Re: [RFC] Add option to mount only a pids subset

On Thu, Mar 23, 2017 at 05:05:07PM +0100, Oleg Nesterov wrote: > Again, I can't really review this, I know nothing about vfs, but since > nobody else replied... Thanks anyway :) > On 03/20, Alexey Gladkov wrote: > > > > @@ -97,7 +169,23 @@ static struct dentry *proc_mount(struct > >

[v1 2/5] mm: defining memblock_virt_alloc_try_nid_raw

A new version of memblock_virt_alloc_* allocations: - Does not zero the allocated memory - Does not panic if request cannot be satisfied Signed-off-by: Pavel Tatashin Reviewed-by: Shannon Nelson --- include/linux/bootmem.h |3 +++

[v1 2/5] mm: defining memblock_virt_alloc_try_nid_raw

A new version of memblock_virt_alloc_* allocations: - Does not zero the allocated memory - Does not panic if request cannot be satisfied Signed-off-by: Pavel Tatashin Reviewed-by: Shannon Nelson --- include/linux/bootmem.h |3 +++ mm/memblock.c | 46

[v1 3/5] mm: add "zero" argument to vmemmap allocators

Allow clients to request non-zeroed memory from vmemmap allocator. The following two public function have a new boolean argument called zero: __vmemmap_alloc_block_buf() vmemmap_alloc_block() When zero is true, memory that is allocated by memblock allocator is zeroed (the current behavior), when

[v1 3/5] mm: add "zero" argument to vmemmap allocators

Allow clients to request non-zeroed memory from vmemmap allocator. The following two public function have a new boolean argument called zero: __vmemmap_alloc_block_buf() vmemmap_alloc_block() When zero is true, memory that is allocated by memblock allocator is zeroed (the current behavior), when

[v1 1/5] sparc64: simplify vmemmap_populate

Remove duplicating code, by using common functions vmemmap_pud_populate and vmemmap_pgd_populate functions. Signed-off-by: Pavel Tatashin Reviewed-by: Shannon Nelson --- arch/sparc/mm/init_64.c | 23 ++- 1 files

[v1 0/5] parallelized "struct page" zeroing

When deferred struct page initialization feature is enabled, we get a performance gain of initializing vmemmap in parallel after other CPUs are started. However, we still zero the memory for vmemmap using one boot CPU. This patch-set fixes the memset-zeroing limitation by deferring it as well.

[v1 1/5] sparc64: simplify vmemmap_populate

Remove duplicating code, by using common functions vmemmap_pud_populate and vmemmap_pgd_populate functions. Signed-off-by: Pavel Tatashin Reviewed-by: Shannon Nelson --- arch/sparc/mm/init_64.c | 23 ++- 1 files changed, 6 insertions(+), 17 deletions(-) diff --git

[v1 0/5] parallelized "struct page" zeroing

When deferred struct page initialization feature is enabled, we get a performance gain of initializing vmemmap in parallel after other CPUs are started. However, we still zero the memory for vmemmap using one boot CPU. This patch-set fixes the memset-zeroing limitation by deferring it as well.

[v1 4/5] mm: zero struct pages during initialization

When deferred struct page initialization is enabled, do not expect that the memory that was allocated for struct pages was zeroed by the allocator. Zero it when "struct pages" are initialized. Also, a defined boolean VMEMMAP_ZERO is provided to tell platforms whether they should zero memory or

[v1 5/5] mm: teach platforms not to zero struct pages memory

If we are using deferred struct page initialization feature, most of "struct page"es are getting initialized after other CPUs are started, and hence we are benefiting from doing this job in parallel. However, we are still zeroing all the memory that is allocated for "struct pages" using the boot

[v1 4/5] mm: zero struct pages during initialization

When deferred struct page initialization is enabled, do not expect that the memory that was allocated for struct pages was zeroed by the allocator. Zero it when "struct pages" are initialized. Also, a defined boolean VMEMMAP_ZERO is provided to tell platforms whether they should zero memory or

[v1 5/5] mm: teach platforms not to zero struct pages memory

If we are using deferred struct page initialization feature, most of "struct page"es are getting initialized after other CPUs are started, and hence we are benefiting from doing this job in parallel. However, we are still zeroing all the memory that is allocated for "struct pages" using the boot

Re: linux-next: manual merge of the gpio tree with the input tree

Hi Dmitry, On Thu, 23 Mar 2017 09:30:49 -0700 Dmitry Torokhov wrote: > > I think the fix is trivial and if it does not both Stephen to carry it > on we'll let the other Linus resolve it in his tree when merging. I > think he prefers to have cross-tree merges only

Re: linux-next: manual merge of the gpio tree with the input tree

Hi Dmitry, On Thu, 23 Mar 2017 09:30:49 -0700 Dmitry Torokhov wrote: > > I think the fix is trivial and if it does not both Stephen to carry it > on we'll let the other Linus resolve it in his tree when merging. I > think he prefers to have cross-tree merges only happen when it is > needed for

Re: [net-next PATCH v2 0/8] Add busy poll support for epoll

On Thu, Mar 23, 2017 at 3:38 PM, Alexander Duyck wrote: > On Thu, Mar 23, 2017 at 3:07 PM, Alexei Starovoitov >> it all sounds awesome, but i cannot quite visualize the impact. >> Can you post some sample code/minibenchmark and numbers before/after? >> >> Thanks! >> >

Re: [net-next PATCH v2 0/8] Add busy poll support for epoll

On Thu, Mar 23, 2017 at 3:38 PM, Alexander Duyck wrote: > On Thu, Mar 23, 2017 at 3:07 PM, Alexei Starovoitov >> it all sounds awesome, but i cannot quite visualize the impact. >> Can you post some sample code/minibenchmark and numbers before/after? >> >> Thanks! >> > > Anything specific you are

Re: [PATCH v3 3/3] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

On Thu, Mar 23, 2017 at 07:08:24AM -0700, Steven Rostedt wrote: > On Thu, 23 Mar 2017 19:36:51 +0900 > Byungchul Park wrote: > > > On Thu, Mar 23, 2017 at 10:44:45AM +0100, Peter Zijlstra wrote: > > > On Thu, Mar 23, 2017 at 11:12:49AM +0900, Byungchul Park wrote: > > >

Re: [PATCH v3 3/3] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

On Thu, Mar 23, 2017 at 07:08:24AM -0700, Steven Rostedt wrote: > On Thu, 23 Mar 2017 19:36:51 +0900 > Byungchul Park wrote: > > > On Thu, Mar 23, 2017 at 10:44:45AM +0100, Peter Zijlstra wrote: > > > On Thu, Mar 23, 2017 at 11:12:49AM +0900, Byungchul Park wrote: > > > > It would be better to

[PATCH] lib/syscall: Clear return values when no stack

Commit aa1f1a639621 ("lib/syscall: Pin the task stack in collect_syscall()") added logic to handle a process stack not existing, but left sp and pc uninitialized, which can be later reported via /proc/$pid/syscall for zombie processes, potentially exposing kernel memory to userspace. Zombie

[PATCH] lib/syscall: Clear return values when no stack

Commit aa1f1a639621 ("lib/syscall: Pin the task stack in collect_syscall()") added logic to handle a process stack not existing, but left sp and pc uninitialized, which can be later reported via /proc/$pid/syscall for zombie processes, potentially exposing kernel memory to userspace. Zombie

Re: [net-next PATCH v2 8/8] net: Introduce SO_INCOMING_NAPI_ID

On Thu, Mar 23, 2017 at 2:38 PM, Alexander Duyck wrote: > From: Sridhar Samudrala > > This socket option returns the NAPI ID associated with the queue on which > the last frame is received. This information can be used by the apps to >

Re: [net-next PATCH v2 8/8] net: Introduce SO_INCOMING_NAPI_ID

On Thu, Mar 23, 2017 at 2:38 PM, Alexander Duyck wrote: > From: Sridhar Samudrala > > This socket option returns the NAPI ID associated with the queue on which > the last frame is received. This information can be used by the apps to > split the incoming flows among the threads based on the Rx

Re: [net-next PATCH v2 0/8] Add busy poll support for epoll

On Thu, Mar 23, 2017 at 3:07 PM, Alexei Starovoitov wrote: > On Thu, Mar 23, 2017 at 02:36:29PM -0700, Alexander Duyck wrote: >> This is my second pass at trying to add support for busy polling when using >> epoll. It is pretty much a full rewrite as I have made

Re: [net-next PATCH v2 0/8] Add busy poll support for epoll

On Thu, Mar 23, 2017 at 3:07 PM, Alexei Starovoitov wrote: > On Thu, Mar 23, 2017 at 02:36:29PM -0700, Alexander Duyck wrote: >> This is my second pass at trying to add support for busy polling when using >> epoll. It is pretty much a full rewrite as I have made serious changes to >> most of the

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