Re: [PATCH v3 17/17] mm, vmscan: make compaction_ready() more accurate and readable

On Fri, Jun 24, 2016 at 11:54:37AM +0200, Vlastimil Babka wrote: > The compaction_ready() is used during direct reclaim for costly order > allocations to skip reclaim for zones where compaction should be attempted > instead. It's combining the standard compaction_suitable() check with its own >

Re: [PATCH v3 17/17] mm, vmscan: make compaction_ready() more accurate and readable

On Fri, Jun 24, 2016 at 11:54:37AM +0200, Vlastimil Babka wrote: > The compaction_ready() is used during direct reclaim for costly order > allocations to skip reclaim for zones where compaction should be attempted > instead. It's combining the standard compaction_suitable() check with its own >

Re: [PATCH v3 13/17] mm, compaction: use correct watermark when checking allocation success

On Fri, Jun 24, 2016 at 11:54:33AM +0200, Vlastimil Babka wrote: > The __compact_finished() function uses low watermark in a check that has to > pass if the direct compaction is to finish and allocation should succeed. This > is too pessimistic, as the allocation will typically use min watermark.

Re: [PATCH v3 13/17] mm, compaction: use correct watermark when checking allocation success

On Fri, Jun 24, 2016 at 11:54:33AM +0200, Vlastimil Babka wrote: > The __compact_finished() function uses low watermark in a check that has to > pass if the direct compaction is to finish and allocation should succeed. This > is too pessimistic, as the allocation will typically use min watermark.

Re: [PATCH v7 1/4] soc: mediatek: Refine scpsys to support multiple platform

Hi Matthias, On Sat, 2016-07-02 at 18:33 +0200, Matthias Brugger wrote: > > On 05/16/2016 11:28 AM, James Liao wrote: > > Refine scpsys driver common code to support multiple SoC / platform. > > > > Signed-off-by: James Liao > > Reviewed-by: Kevin Hilman

Re: [PATCH v7 1/4] soc: mediatek: Refine scpsys to support multiple platform

Hi Matthias, On Sat, 2016-07-02 at 18:33 +0200, Matthias Brugger wrote: > > On 05/16/2016 11:28 AM, James Liao wrote: > > Refine scpsys driver common code to support multiple SoC / platform. > > > > Signed-off-by: James Liao > > Reviewed-by: Kevin Hilman > > --- > >

Re: [PATCH] KVM: VMX: switch to hrtimer for TSC deadline timer when L2 guest is running

Cc Jan, 2016-07-06 13:10 GMT+08:00 Haozhong Zhang : > A different VMCS is loaded when L2 guest is running, so it's incorrect > to use the VMX preemption timer for L1 TSC deadline timer. This patch > switches to hrtimer for L1 TSC deadline timer when entering L2 guest, >

Re: [PATCH] KVM: VMX: switch to hrtimer for TSC deadline timer when L2 guest is running

Cc Jan, 2016-07-06 13:10 GMT+08:00 Haozhong Zhang : > A different VMCS is loaded when L2 guest is running, so it's incorrect > to use the VMX preemption timer for L1 TSC deadline timer. This patch > switches to hrtimer for L1 TSC deadline timer when entering L2 guest, > and switches back to VMX

Re: [PATCH v3 12/17] mm, compaction: more reliably increase direct compaction priority

On Fri, Jun 24, 2016 at 11:54:32AM +0200, Vlastimil Babka wrote: > During reclaim/compaction loop, compaction priority can be increased by the > should_compact_retry() function, but the current code is not optimal. Priority > is only increased when compaction_failed() is true, which means that >

Re: [PATCH v3 12/17] mm, compaction: more reliably increase direct compaction priority

On Fri, Jun 24, 2016 at 11:54:32AM +0200, Vlastimil Babka wrote: > During reclaim/compaction loop, compaction priority can be increased by the > should_compact_retry() function, but the current code is not optimal. Priority > is only increased when compaction_failed() is true, which means that >

Re: [PATCH] lockdep: Add a document describing crossrelease feature

On Wed, Jul 06, 2016 at 11:17:10AM +0900, Byungchul Park wrote: > > lock(A) > wait_for(B) > <- serialized by atomic operation > lock(A) > unlock(A) > wake(B) > unlock(A) By the way, I have a question. Is there anyone who could

[PATCH] clocksource: cadence_ttc: fix a return value in case of error

IS_ERR and PTR_ERR should use the same variable, clk_ce in this case. Fixes: 4de1eb07c47f (Convert init function to return error) Signed-off-by: Christophe JAILLET --- drivers/clocksource/cadence_ttc_timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH] lockdep: Add a document describing crossrelease feature

On Wed, Jul 06, 2016 at 11:17:10AM +0900, Byungchul Park wrote: > > lock(A) > wait_for(B) > <- serialized by atomic operation > lock(A) > unlock(A) > wake(B) > unlock(A) By the way, I have a question. Is there anyone who could

[PATCH] clocksource: cadence_ttc: fix a return value in case of error

IS_ERR and PTR_ERR should use the same variable, clk_ce in this case. Fixes: 4de1eb07c47f (Convert init function to return error) Signed-off-by: Christophe JAILLET --- drivers/clocksource/cadence_ttc_timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: porting kcov to android

Well, something is broken. Shadow in the report is complete mess (fc is heap redzone, while f4 is stack redzone). I wonder if it is the bootstrap shadow page that is used for both heap and stack. Or maybe we return poisoned pages to pagealloc. The first thing I would try is to disable stack and

Re: porting kcov to android

Well, something is broken. Shadow in the report is complete mess (fc is heap redzone, while f4 is stack redzone). I wonder if it is the bootstrap shadow page that is used for both heap and stack. Or maybe we return poisoned pages to pagealloc. The first thing I would try is to disable stack and

Re: [PATCH v7 2/4] soc: mediatek: Init MT8173 scpsys driver earlier

On Sat, 2016-07-02 at 18:35 +0200, Matthias Brugger wrote: > > On 05/16/2016 11:28 AM, James Liao wrote: > > Some power domain comsumers may init before module_init. > > So the power domain provider (scpsys) need to be initialized > > earlier too. > > > > Take an example for our IOMMU (M4U) and

[PATCH v5 2/7] perf config: Add macros assigning key-value pairs to default_config_item

In near future, default_config_item arrays will be added (e.g. const struct default_config_item colors_config_items[]) To simply assign config key-value pairs to default_config_item, add macros that are CONF_VAR() and CONF_*_VAR() for each type. Cc: Namhyung Kim Cc: Jiri

Re: [PATCH v7 2/4] soc: mediatek: Init MT8173 scpsys driver earlier

On Sat, 2016-07-02 at 18:35 +0200, Matthias Brugger wrote: > > On 05/16/2016 11:28 AM, James Liao wrote: > > Some power domain comsumers may init before module_init. > > So the power domain provider (scpsys) need to be initialized > > earlier too. > > > > Take an example for our IOMMU (M4U) and

[PATCH v5 2/7] perf config: Add macros assigning key-value pairs to default_config_item

In near future, default_config_item arrays will be added (e.g. const struct default_config_item colors_config_items[]) To simply assign config key-value pairs to default_config_item, add macros that are CONF_VAR() and CONF_*_VAR() for each type. Cc: Namhyung Kim Cc: Jiri Olsa Cc: Wang Nan Cc:

[PATCH v5 7/7] perf config: Initialize annotate_browser__opts with default config items

Set default config values for 'annotate' section with 'annotate_config_items[]' instead of actual bool type values. (e.g. using annotate_config_items[CONFIG_ANNOTATE_USE_OFFSET].value instead of 'true' bool type value for 'annotate.use_offset'.) Cc: Namhyung Kim Cc: Jiri

[PATCH v5 7/7] perf config: Initialize annotate_browser__opts with default config items

Set default config values for 'annotate' section with 'annotate_config_items[]' instead of actual bool type values. (e.g. using annotate_config_items[CONFIG_ANNOTATE_USE_OFFSET].value instead of 'true' bool type value for 'annotate.use_offset'.) Cc: Namhyung Kim Cc: Jiri Olsa Cc: Masami

[PATCH v5 4/7] perf config: Use combined {fore,back}ground colors value instead of each two color

To manage all default config values at one spot (at util/config.c), it would be better that actual variables for each 'colors' config also have only one value like 'default_config_item' type. If we do, it smoothly work to initialize 'colors' default config values by 'colors_config_items' array

[PATCH v5 6/7] perf config: Add 'annotate' section default configs arrrays

Actual variable for configs of 'annotate' section is like below. (at ui/browsers/annoate.c) static struct annotate_browser_opt { bool hide_src_code, use_offset, jump_arrows, show_linenr, show_nr_jumps, show_total_period; }

[PATCH v5 5/7] perf config: Initialize ui_browser__colorsets with default config items

Set default config values for 'colors' section with 'colors_config_items[]' instead of actual const char * type values. (e.g. using colors_config_item[CONFIG_COLORS_TOP].value instead of "red, default" string value for 'colors.top') Cc: Namhyung Kim Cc: Jiri Olsa

[PATCH v5 4/7] perf config: Use combined {fore,back}ground colors value instead of each two color

To manage all default config values at one spot (at util/config.c), it would be better that actual variables for each 'colors' config also have only one value like 'default_config_item' type. If we do, it smoothly work to initialize 'colors' default config values by 'colors_config_items' array

[PATCH v5 6/7] perf config: Add 'annotate' section default configs arrrays

Actual variable for configs of 'annotate' section is like below. (at ui/browsers/annoate.c) static struct annotate_browser_opt { bool hide_src_code, use_offset, jump_arrows, show_linenr, show_nr_jumps, show_total_period; }

[PATCH v5 5/7] perf config: Initialize ui_browser__colorsets with default config items

Set default config values for 'colors' section with 'colors_config_items[]' instead of actual const char * type values. (e.g. using colors_config_item[CONFIG_COLORS_TOP].value instead of "red, default" string value for 'colors.top') Cc: Namhyung Kim Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Wang

[PATCH v5 1/7] perf config: Introduce default_config_section and default_config_item for default config key-value pairs

When initializing default perf config values, we currently use values of actual type(int, bool, char *, etc.). For example, If there isn't user config value at ~/.perfconfig for 'annotate.use_offset' config variable, default value for it is 'true' bool type value in perf like below. At

[RFC PATCH v5 0/7] perf config: Introduce default config key-value pairs arrays

Hello, :) When initializing default perf config values, we currently use values of actual type(int, bool, char *, etc.). But I suggest using default config key-value pairs arrays. For example, If there isn't user config value at ~/.perfconfig for 'annotate.use_offset' config variable, default

[PATCH v5 3/7] perf config: Add 'colors' section default configs arrrays

Actual variable for configs of 'colors' section is like below. (at ui/browser.c) static struct ui_browser_colorset { const char *name, *fg, *bg; int colorset; } ui_browser__colorsets[] = { { .colorset = HE_COLORSET_TOP, .name = "top",

[PATCH v5 1/7] perf config: Introduce default_config_section and default_config_item for default config key-value pairs

When initializing default perf config values, we currently use values of actual type(int, bool, char *, etc.). For example, If there isn't user config value at ~/.perfconfig for 'annotate.use_offset' config variable, default value for it is 'true' bool type value in perf like below. At

[RFC PATCH v5 0/7] perf config: Introduce default config key-value pairs arrays

Hello, :) When initializing default perf config values, we currently use values of actual type(int, bool, char *, etc.). But I suggest using default config key-value pairs arrays. For example, If there isn't user config value at ~/.perfconfig for 'annotate.use_offset' config variable, default

[PATCH v5 3/7] perf config: Add 'colors' section default configs arrrays

Actual variable for configs of 'colors' section is like below. (at ui/browser.c) static struct ui_browser_colorset { const char *name, *fg, *bg; int colorset; } ui_browser__colorsets[] = { { .colorset = HE_COLORSET_TOP, .name = "top",

Re: [PATCH v7 4/4] soc: mediatek: Add MT2701 scpsys driver

On Sat, 2016-07-02 at 18:41 +0200, Matthias Brugger wrote: > > On 05/16/2016 11:28 AM, James Liao wrote: > > From: Shunli Wang > > > > Add scpsys driver for MT2701. > > > > mtk-scpsys now supports MT8173 (arm64) and MT2701 (arm). So it should > > be enabled on both

Re: [PATCH v7 4/4] soc: mediatek: Add MT2701 scpsys driver

On Sat, 2016-07-02 at 18:41 +0200, Matthias Brugger wrote: > > On 05/16/2016 11:28 AM, James Liao wrote: > > From: Shunli Wang > > > > Add scpsys driver for MT2701. > > > > mtk-scpsys now supports MT8173 (arm64) and MT2701 (arm). So it should > > be enabled on both arm64 and arm platforms. > > >

[PATCH v2 2/3] arm/xen: add support for vm_assist hypercall

Add support for the Xen HYPERVISOR_vm_assist hypercall. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Reviewed-by: Julien Grall Reviewed-by: Stefano Stabellini ---

[PATCH v2 2/3] arm/xen: add support for vm_assist hypercall

Add support for the Xen HYPERVISOR_vm_assist hypercall. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Reviewed-by: Julien Grall Reviewed-by: Stefano Stabellini --- arch/arm/include/asm/xen/hypercall.h | 1 + arch/arm/xen/enlighten.c | 1 + arch/arm/xen/hypercall.S

[PATCH] KVM: VMX: switch to hrtimer for TSC deadline timer when L2 guest is running

A different VMCS is loaded when L2 guest is running, so it's incorrect to use the VMX preemption timer for L1 TSC deadline timer. This patch switches to hrtimer for L1 TSC deadline timer when entering L2 guest, and switches back to VMX preemption timer when nested VMEXIT from L2 to L1.

[PATCH] KVM: VMX: switch to hrtimer for TSC deadline timer when L2 guest is running

A different VMCS is loaded when L2 guest is running, so it's incorrect to use the VMX preemption timer for L1 TSC deadline timer. This patch switches to hrtimer for L1 TSC deadline timer when entering L2 guest, and switches back to VMX preemption timer when nested VMEXIT from L2 to L1.

Re: [PATCH 2/2] i2c-dev: Don't block the adapter from unregistering

Hi, [auto build test WARNING on wsa/i2c/for-next] [also build test WARNING on v4.7-rc6 next-20160705] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Viresh-Kumar/i2c-dev-Don-t-let-userspace

Re: [PATCH 2/2] i2c-dev: Don't block the adapter from unregistering

Hi, [auto build test WARNING on wsa/i2c/for-next] [also build test WARNING on v4.7-rc6 next-20160705] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Viresh-Kumar/i2c-dev-Don-t-let-userspace

Re: [PATCH v3 09/17] mm, compaction: make whole_zone flag ignore cached scanner positions

On Fri, Jun 24, 2016 at 11:54:29AM +0200, Vlastimil Babka wrote: > A recent patch has added whole_zone flag that compaction sets when scanning > starts from the zone boundary, in order to report that zone has been fully > scanned in one attempt. For allocations that want to try really hard or

Re: [PATCH v3 09/17] mm, compaction: make whole_zone flag ignore cached scanner positions

On Fri, Jun 24, 2016 at 11:54:29AM +0200, Vlastimil Babka wrote: > A recent patch has added whole_zone flag that compaction sets when scanning > starts from the zone boundary, in order to report that zone has been fully > scanned in one attempt. For allocations that want to try really hard or

Re: [PATCH net] net: mvneta: set real interrupt per packet for tx_done

Hi, On Wed, Jul 06, 2016 at 04:18:58AM +0200, Marcin Wojtas wrote: > From: Dmitri Epshtein > > Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to > set coalescing threshold to a value guaranteeing interrupt generation > per each sent packet, so that

Re: [PATCH net] net: mvneta: set real interrupt per packet for tx_done

Hi, On Wed, Jul 06, 2016 at 04:18:58AM +0200, Marcin Wojtas wrote: > From: Dmitri Epshtein > > Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to > set coalescing threshold to a value guaranteeing interrupt generation > per each sent packet, so that buffers can be released

[PATCH v2 0/3] xen: add full support for CONFIG_PARAVIRT_TIME_ACCOUNTING

With most recent Xen hypervisor (4.8) it is now possible to add full support of CONFIG_PARAVIRT_TIME_ACCOUNTING. To be applied on top of commit ed2f61fdd2356c2a1d1239aa1507ce4e2e059306 "xen: add steal_clock support on x86" of kernel/git/xen/tip.git Runtime tested on x86_64, compile tested on

[PATCH v2 3/3] xen: support runqueue steal time on xen

Up to now reading the stolen time of a remote cpu was not possible in a performant way under Xen. This made support of runqueue steal time via paravirt_steal_rq_enabled impossible. With the addition of an appropriate hypervisor interface this is now possible, so add the support. Signed-off-by:

[PATCH v2 1/3] xen: update xen headers

Update some Xen headers to be able to use new functionality. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Reviewed-by: Stefano Stabellini --- include/xen/interface/vcpu.h | 24 +++-

[PATCH v2 0/3] xen: add full support for CONFIG_PARAVIRT_TIME_ACCOUNTING

With most recent Xen hypervisor (4.8) it is now possible to add full support of CONFIG_PARAVIRT_TIME_ACCOUNTING. To be applied on top of commit ed2f61fdd2356c2a1d1239aa1507ce4e2e059306 "xen: add steal_clock support on x86" of kernel/git/xen/tip.git Runtime tested on x86_64, compile tested on

[PATCH v2 3/3] xen: support runqueue steal time on xen

Up to now reading the stolen time of a remote cpu was not possible in a performant way under Xen. This made support of runqueue steal time via paravirt_steal_rq_enabled impossible. With the addition of an appropriate hypervisor interface this is now possible, so add the support. Signed-off-by:

[PATCH v2 1/3] xen: update xen headers

Update some Xen headers to be able to use new functionality. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky Reviewed-by: Stefano Stabellini --- include/xen/interface/vcpu.h | 24 +++- include/xen/interface/xen.h | 17 - 2 files changed, 31

Re: [PATCH v2 2/4] powerpc/spinlock: support vcpu preempted check

Hi, wanpeng On 2016年07月05日 17:57, Wanpeng Li wrote: Hi Xinhui, 2016-06-28 22:43 GMT+08:00 Pan Xinhui : This is to fix some lock holder preemption issues. Some other locks implementation do a spin loop before acquiring the lock itself. Currently kernel has an

Re: [PATCH v2 2/4] powerpc/spinlock: support vcpu preempted check

Hi, wanpeng On 2016年07月05日 17:57, Wanpeng Li wrote: Hi Xinhui, 2016-06-28 22:43 GMT+08:00 Pan Xinhui : This is to fix some lock holder preemption issues. Some other locks implementation do a spin loop before acquiring the lock itself. Currently kernel has an interface of bool

Re: [PATCH v3 1/2] clk: exynos5433: do not use CLK_IGNORE_UNUSED for SPI clocks

Hi Sylwester, > +#if 0 > clocks = <_peric CLK_PCLK_SPI1>, > <_top CLK_SCLK_SPI1_PERIC>; > +#else > + clocks = <_peric CLK_PCLK_SPI1>, > +<_peric CLK_SCLK_SPI1>; > +#endif Yes, that's

Re: [PATCH v3 1/2] clk: exynos5433: do not use CLK_IGNORE_UNUSED for SPI clocks

Hi Sylwester, > +#if 0 > clocks = <_peric CLK_PCLK_SPI1>, > <_top CLK_SCLK_SPI1_PERIC>; > +#else > + clocks = <_peric CLK_PCLK_SPI1>, > +<_peric CLK_SCLK_SPI1>; > +#endif Yes, that's

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

On Jul 5, 2016, at 11:25 PM, Oleg Drokin wrote: > > On Jul 5, 2016, at 11:20 PM, Al Viro wrote: > >> On Tue, Jul 05, 2016 at 08:29:37PM -0400, Oleg Drokin wrote: + /* Otherwise we just unhash it to be rehashed afresh via + * lookup if necessary + */

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

On Jul 5, 2016, at 11:25 PM, Oleg Drokin wrote: > > On Jul 5, 2016, at 11:20 PM, Al Viro wrote: > >> On Tue, Jul 05, 2016 at 08:29:37PM -0400, Oleg Drokin wrote: + /* Otherwise we just unhash it to be rehashed afresh via + * lookup if necessary + */

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

Hi There, On 05.07.2016 10:33, Icenowy Zheng wrote: On 01.07.2016 11:29, Icenowy Zheng wrote: + +static enum power_supply_property axp22x_battery_properties[] = { + POWER_SUPPLY_PROP_CAPACITY, + POWER_SUPPLY_PROP_HEALTH, + POWER_SUPPLY_PROP_PRESENT, + POWER_SUPPLY_PROP_STATUS,

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

Hi There, On 05.07.2016 10:33, Icenowy Zheng wrote: On 01.07.2016 11:29, Icenowy Zheng wrote: + +static enum power_supply_property axp22x_battery_properties[] = { + POWER_SUPPLY_PROP_CAPACITY, + POWER_SUPPLY_PROP_HEALTH, + POWER_SUPPLY_PROP_PRESENT, + POWER_SUPPLY_PROP_STATUS,

Re: [PATCH 5/5] overlayfs: Use vfs_getxattr_noperm() for real inode

On Tue, Jul 5, 2016 at 11:16 PM, Vivek Goyal wrote: > On Tue, Jul 05, 2016 at 01:29:39PM -0700, Casey Schaufler wrote: >> On 7/5/2016 8:50 AM, Vivek Goyal wrote: >> > ovl_getxattr() currently uses vfs_getxattr() on realinode. This fails >> > if mounter does not have DAC/MAC

Re: [PATCH 5/5] overlayfs: Use vfs_getxattr_noperm() for real inode

On Tue, Jul 5, 2016 at 11:16 PM, Vivek Goyal wrote: > On Tue, Jul 05, 2016 at 01:29:39PM -0700, Casey Schaufler wrote: >> On 7/5/2016 8:50 AM, Vivek Goyal wrote: >> > ovl_getxattr() currently uses vfs_getxattr() on realinode. This fails >> > if mounter does not have DAC/MAC permission to access

Re: [PATCH v2 0/7] lib: string: add functions to case-convert strings

On 5 July 2016 at 15:56, Joe Perches wrote: > On Tue, 2016-07-05 at 15:36 -0700, Markus Mayer wrote: >> On 5 July 2016 at 15:14, Joe Perches wrote: >> > On Tue, 2016-07-05 at 13:47 -0700, Markus Mayer wrote: >> > > This series introduces a family of generic

Re: [PATCH v2 0/7] lib: string: add functions to case-convert strings

On 5 July 2016 at 15:56, Joe Perches wrote: > On Tue, 2016-07-05 at 15:36 -0700, Markus Mayer wrote: >> On 5 July 2016 at 15:14, Joe Perches wrote: >> > On Tue, 2016-07-05 at 13:47 -0700, Markus Mayer wrote: >> > > This series introduces a family of generic string case conversion >> > >

Re: [PATCH 04/14] PCI: generic: make it explicitly non-modular

On Wed, Jul 6, 2016 at 1:49 AM, David Daney wrote: > > On 07/04/2016 10:37 AM, Will Deacon wrote: >> >> On Sat, Jul 02, 2016 at 07:13:24PM -0400, Paul Gortmaker wrote: >>> >>> The Kconfig currently controlling compilation of this code is: >>> >>>

Re: [PATCH 3/3] xen: support runqueue steal time on xen

On 05/07/16 17:23, Stefano Stabellini wrote: > On Wed, 22 Jun 2016, Juergen Gross wrote: >> Up to now reading the stolen time of a remote cpu was not possible in a >> performant way under Xen. This made support of runqueue steal time via >> paravirt_steal_rq_enabled impossible. >> >> With the

Re: [PATCH 3/3] xen: support runqueue steal time on xen

On 05/07/16 17:23, Stefano Stabellini wrote: > On Wed, 22 Jun 2016, Juergen Gross wrote: >> Up to now reading the stolen time of a remote cpu was not possible in a >> performant way under Xen. This made support of runqueue steal time via >> paravirt_steal_rq_enabled impossible. >> >> With the

Re: [PATCH 04/14] PCI: generic: make it explicitly non-modular

On Wed, Jul 6, 2016 at 1:49 AM, David Daney wrote: > > On 07/04/2016 10:37 AM, Will Deacon wrote: >> >> On Sat, Jul 02, 2016 at 07:13:24PM -0400, Paul Gortmaker wrote: >>> >>> The Kconfig currently controlling compilation of this code is: >>> >>> drivers/pci/host/Kconfig:config PCI_HOST_GENERIC

Re: [f2fs-dev] [PATCH 1/2] f2fs: check only data or node for summary

On 2016/6/11 5:01, Jaegeuk Kim wrote: We can check data or node types only for gc, since we allocate different type of data/node blocks in a different logs occasionally. Signed-off-by: Jaegeuk Kim --- fs/f2fs/gc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

Re: [f2fs-dev] [PATCH 1/2] f2fs: check only data or node for summary

On 2016/6/11 5:01, Jaegeuk Kim wrote: We can check data or node types only for gc, since we allocate different type of data/node blocks in a different logs occasionally. Signed-off-by: Jaegeuk Kim --- fs/f2fs/gc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Wed, Jul 06, 2016 at 10:22:59AM +0800, Xiao Guangrong wrote: > > > On 07/05/2016 11:07 PM, Neo Jia wrote: > >This is kept there in case the validate_map_request() is not provided by > >vendor > >driver then by default assume 1:1 mapping. So if validate_map_request() is > >not > >provided,

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Wed, Jul 06, 2016 at 10:22:59AM +0800, Xiao Guangrong wrote: > > > On 07/05/2016 11:07 PM, Neo Jia wrote: > >This is kept there in case the validate_map_request() is not provided by > >vendor > >driver then by default assume 1:1 mapping. So if validate_map_request() is > >not > >provided,

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On 07/06/2016 10:57 AM, Neo Jia wrote: On Wed, Jul 06, 2016 at 10:35:18AM +0800, Xiao Guangrong wrote: On 07/06/2016 10:18 AM, Neo Jia wrote: On Wed, Jul 06, 2016 at 10:00:46AM +0800, Xiao Guangrong wrote: On 07/05/2016 08:18 PM, Paolo Bonzini wrote: On 05/07/2016 07:41, Neo Jia

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On 07/06/2016 10:57 AM, Neo Jia wrote: On Wed, Jul 06, 2016 at 10:35:18AM +0800, Xiao Guangrong wrote: On 07/06/2016 10:18 AM, Neo Jia wrote: On Wed, Jul 06, 2016 at 10:00:46AM +0800, Xiao Guangrong wrote: On 07/05/2016 08:18 PM, Paolo Bonzini wrote: On 05/07/2016 07:41, Neo Jia

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

On Jul 5, 2016, at 11:20 PM, Al Viro wrote: > On Tue, Jul 05, 2016 at 08:29:37PM -0400, Oleg Drokin wrote: >>> + /* Otherwise we just unhash it to be rehashed afresh via >>> +* lookup if necessary >>> +*/ >>> + d_drop(dentry); >> >> So we can even

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

On Jul 5, 2016, at 11:20 PM, Al Viro wrote: > On Tue, Jul 05, 2016 at 08:29:37PM -0400, Oleg Drokin wrote: >>> + /* Otherwise we just unhash it to be rehashed afresh via >>> +* lookup if necessary >>> +*/ >>> + d_drop(dentry); >> >> So we can even

Re: [PATCH 2/2] s390/mm: use ipte range to invalidate multiple page table entries

> > +void ptep_invalidate_range(struct mm_struct *mm, unsigned long start, > +unsigned long end, pte_t *ptep) > +{ > + unsigned long nr; > + > + if (!MACHINE_HAS_IPTE_RANGE || mm_has_pgste(mm)) > + return; > + preempt_disable(); > + nr = (end -

Re: [PATCH 2/2] s390/mm: use ipte range to invalidate multiple page table entries

> > +void ptep_invalidate_range(struct mm_struct *mm, unsigned long start, > +unsigned long end, pte_t *ptep) > +{ > + unsigned long nr; > + > + if (!MACHINE_HAS_IPTE_RANGE || mm_has_pgste(mm)) > + return; > + preempt_disable(); > + nr = (end -

Re: [GIT PULL 3/3] bcm2835-arm64-next-2016-07-03

Le 05/07/2016 11:03, Jason Cooper a écrit : > Eric, > > On Sun, Jul 03, 2016 at 05:45:36PM -0700, Eric Anholt wrote: >> Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) >> >> are available in the git repository at: >> >> https://github.com/anholt/linux tags/bcm2835-arm64-next-2016-07-03 >> >> for

Re: [GIT PULL 3/3] bcm2835-arm64-next-2016-07-03

Le 05/07/2016 11:03, Jason Cooper a écrit : > Eric, > > On Sun, Jul 03, 2016 at 05:45:36PM -0700, Eric Anholt wrote: >> Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) >> >> are available in the git repository at: >> >> https://github.com/anholt/linux tags/bcm2835-arm64-next-2016-07-03 >> >> for

Re: [GIT PULL 2/3] bcm2835-dt-64-next-2016-07-03

Le 03/07/2016 17:45, Eric Anholt a écrit : > Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) > > are available in the git repository at: > > https://github.com/anholt/linux tags/bcm2835-dt-64-next-2016-07-03 > > for you to fetch changes up to 02d08603649816a941246c18252e5c41fd07625a: > > ARM:

Re: [GIT PULL 2/3] bcm2835-dt-64-next-2016-07-03

Le 03/07/2016 17:45, Eric Anholt a écrit : > Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) > > are available in the git repository at: > > https://github.com/anholt/linux tags/bcm2835-dt-64-next-2016-07-03 > > for you to fetch changes up to 02d08603649816a941246c18252e5c41fd07625a: > > ARM:

Re: [GIT PULL 1/3] bcm2835-dt-next-2016-07-03

Le 03/07/2016 17:45, Eric Anholt a écrit : > Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) > > are available in the git repository at: > > https://github.com/anholt/linux tags/bcm2835-dt-next-2016-07-03 > > for you to fetch changes up to 6a93792774fc72861b7e8efaa3545a88272b4413: > > ARM:

Re: [GIT PULL 1/3] bcm2835-dt-next-2016-07-03

Le 03/07/2016 17:45, Eric Anholt a écrit : > Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) > > are available in the git repository at: > > https://github.com/anholt/linux tags/bcm2835-dt-next-2016-07-03 > > for you to fetch changes up to 6a93792774fc72861b7e8efaa3545a88272b4413: > > ARM:

[PATCH v3] fs/dcache.c: avoid soft-lockup in dput()

We triggered soft-lockup under stress test which open/access/write/close one file concurrently on more than five different CPUs: WARN: soft lockup - CPU#0 stuck for 11s! [who:30631] ... [] dput+0x100/0x298 [] terminate_walk+0x4c/0x60 [] path_lookupat+0x5cc/0x7a8 [] filename_lookup+0x38/0xf0 []

[PATCH v3] fs/dcache.c: avoid soft-lockup in dput()

We triggered soft-lockup under stress test which open/access/write/close one file concurrently on more than five different CPUs: WARN: soft lockup - CPU#0 stuck for 11s! [who:30631] ... [] dput+0x100/0x298 [] terminate_walk+0x4c/0x60 [] path_lookupat+0x5cc/0x7a8 [] filename_lookup+0x38/0xf0 []

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

On Tue, Jul 05, 2016 at 08:29:37PM -0400, Oleg Drokin wrote: > > + /* Otherwise we just unhash it to be rehashed afresh via > > +* lookup if necessary > > +*/ > > + d_drop(dentry); > > So we can even drop this part and retain the top condition as it

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

On Tue, Jul 05, 2016 at 08:29:37PM -0400, Oleg Drokin wrote: > > + /* Otherwise we just unhash it to be rehashed afresh via > > +* lookup if necessary > > +*/ > > + d_drop(dentry); > > So we can even drop this part and retain the top condition as it

Re: [RESEND PATCH v5 1/5] mfd: RK808: Add RK818 support

Hi Wadim: On 2016年06月09日 16:23, Wadim Egorov wrote: Hi, On 08.06.2016 16:17, Lee Jones wrote: On Thu, 02 Jun 2016, Wadim Egorov wrote: The RK818 chip is a power management IC for multimedia and handheld "Power Management IC (PMIC)" devices. It contains the following components: -

Re: [RESEND PATCH v5 1/5] mfd: RK808: Add RK818 support

Hi Wadim: On 2016年06月09日 16:23, Wadim Egorov wrote: Hi, On 08.06.2016 16:17, Lee Jones wrote: On Thu, 02 Jun 2016, Wadim Egorov wrote: The RK818 chip is a power management IC for multimedia and handheld "Power Management IC (PMIC)" devices. It contains the following components: -

Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

On 06.07.2016 06:06, Tejun Heo wrote: > On Mon, Jul 04, 2016 at 12:58:32PM +0900, Michel Dänzer wrote: >> On 02.07.2016 22:46, Tejun Heo wrote: >>> On Sat, Jul 02, 2016 at 04:33:50PM +0530, Bhaktipriya Shridhar wrote: alloc_workqueue replaces deprecated create_singlethread_workqueue().

Re: [PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

On 06.07.2016 06:06, Tejun Heo wrote: > On Mon, Jul 04, 2016 at 12:58:32PM +0900, Michel Dänzer wrote: >> On 02.07.2016 22:46, Tejun Heo wrote: >>> On Sat, Jul 02, 2016 at 04:33:50PM +0530, Bhaktipriya Shridhar wrote: alloc_workqueue replaces deprecated create_singlethread_workqueue().

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Wed, Jul 06, 2016 at 10:35:18AM +0800, Xiao Guangrong wrote: > > > On 07/06/2016 10:18 AM, Neo Jia wrote: > >On Wed, Jul 06, 2016 at 10:00:46AM +0800, Xiao Guangrong wrote: > >> > >> > >>On 07/05/2016 08:18 PM, Paolo Bonzini wrote: > >>> > >>> > >>>On 05/07/2016 07:41, Neo Jia wrote: > On

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Wed, Jul 06, 2016 at 10:35:18AM +0800, Xiao Guangrong wrote: > > > On 07/06/2016 10:18 AM, Neo Jia wrote: > >On Wed, Jul 06, 2016 at 10:00:46AM +0800, Xiao Guangrong wrote: > >> > >> > >>On 07/05/2016 08:18 PM, Paolo Bonzini wrote: > >>> > >>> > >>>On 05/07/2016 07:41, Neo Jia wrote: > On

[PATCH 0/2] i2c-dev: Don't let userspace block adapter

Hi Wolfram/Jean, I am part of the kernel team for Google's projectara [1], where we are building a module smart phone. This series tries to fix one of the problems we hit on our system as we are required to hotplug pretty much every thing on the phone and so this fixes hotplug issues with

[PATCH 0/2] i2c-dev: Don't let userspace block adapter

Hi Wolfram/Jean, I am part of the kernel team for Google's projectara [1], where we are building a module smart phone. This series tries to fix one of the problems we hit on our system as we are required to hotplug pretty much every thing on the phone and so this fixes hotplug issues with

[PATCH 2/2] i2c-dev: Don't block the adapter from unregistering

The i2c-dev calls i2c_get_adapter() from the .open() callback, which doesn't let the adapter device unregister unless the .close() callback is called. On some platforms (like Google ARA), this doesn't let the modules (hardware attached to the phone) eject from the phone as the cleanup path for

[PATCH 1/2] i2c-dev: don't get i2c adapter via i2c_dev

There is no code protecting i2c_dev to be freed after it is returned from i2c_dev_get_by_minor() and using it to access the value which we already have (minor) isn't safe really. Avoid using it and get the adapter directly from 'minor'. Signed-off-by: Viresh Kumar ---

[PATCH 2/2] i2c-dev: Don't block the adapter from unregistering

The i2c-dev calls i2c_get_adapter() from the .open() callback, which doesn't let the adapter device unregister unless the .close() callback is called. On some platforms (like Google ARA), this doesn't let the modules (hardware attached to the phone) eject from the phone as the cleanup path for

[PATCH 1/2] i2c-dev: don't get i2c adapter via i2c_dev

There is no code protecting i2c_dev to be freed after it is returned from i2c_dev_get_by_minor() and using it to access the value which we already have (minor) isn't safe really. Avoid using it and get the adapter directly from 'minor'. Signed-off-by: Viresh Kumar --- drivers/i2c/i2c-dev.c | 7

  1   2   3   4   5   6   7   8   9   10   >