RE: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional
> How about naming it as PM_SLEEP_FS_SYNC (and similarly in the sysfs > files > and variable names as well). Just to avoid confusion with > "synchronous/async". good point -- thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] suspend: make sync() on suspend-to-RAM optional
From: Len Brown
Linux suspend-to-RAM was unreliable when first developed,
and so sys_sync() was invoked inside the kernel at the
start of every suspend flow.
Today, many devices are invoking suspend with
high reliability and high frequency, and they don't
want to be forced to pay for sync on every suspend.
So here we make it optional.
De-select CONFIG_PM_SUSPEND_SYNC to delete the call entirely.
or keep CONFIG_PM_SUSPEND_SYNC and you can now clear the
sys/power/suspend_sync attribte to disable the sync
from user-space.
As we have had this call for a long time,
the default remains to keep the call, and to
invoke it on every suspend.
Signed-off-by: Len Brown
---
kernel/power/Kconfig | 8
kernel/power/main.c| 33 +
kernel/power/power.h | 1 +
kernel/power/suspend.c | 10 +++---
4 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 2fac9cc..61c7bd1 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -102,6 +102,14 @@ config PM_SLEEP_SMP
depends on PM_SLEEP
select HOTPLUG_CPU
+config SUSPEND_SYNC
+ bool "Suspend to RAM starts with in-kernel call to sync()"
+ default y
+ depends on SUSPEND
+ ---help---
+ Build a call to sync() into the Linux kernel suspend to RAM flow.
+ The sync can still be skipped by clearing /sys/power/suspend_sync.
+
config PM_AUTOSLEEP
bool "Opportunistic sleep"
depends on PM_SLEEP
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 1d1bf63..bd7eeeb 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -71,6 +71,36 @@ static ssize_t pm_async_store(struct kobject *kobj, struct
kobj_attribute *attr,
power_attr(pm_async);
+#ifdef CONFIG_SUSPEND_SYNC
+
+/* If set, sync file systems at start of suspend flow */
+int suspend_sync_enabled = 1;
+
+static ssize_t suspend_sync_show(struct kobject *kobj, struct kobj_attribute
*attr,
+char *buf)
+{
+ return sprintf(buf, "%d\n", suspend_sync_enabled);
+}
+
+static ssize_t suspend_sync_store(struct kobject *kobj, struct kobj_attribute
*attr,
+ const char *buf, size_t n)
+{
+ unsigned long val;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ if (val > 1)
+ return -EINVAL;
+
+ suspend_sync_enabled = val;
+ return n;
+}
+
+power_attr(suspend_sync);
+
+#endif /* CONFIG_SUSPEND_SYNC */
+
#ifdef CONFIG_PM_DEBUG
int pm_test_level = TEST_NONE;
@@ -592,6 +622,9 @@ static struct attribute * g[] = {
#ifdef CONFIG_PM_SLEEP
&pm_async_attr.attr,
&wakeup_count_attr.attr,
+#ifdef CONFIG_PM_SLEEP_SYNC
+ &suspend_sync_attr.attr,
+#endif
#ifdef CONFIG_PM_AUTOSLEEP
&autosleep_attr.attr,
#endif
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 7d4b7ff..7dd66ff 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -200,6 +200,7 @@ static inline void suspend_test_finish(const char *label) {}
#ifdef CONFIG_PM_SLEEP
/* kernel/power/main.c */
extern int pm_notifier_call_chain(unsigned long val);
+extern int suspend_sync_enabled;
#endif
#ifdef CONFIG_HIGHMEM
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 62ee437..5155cb9 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -333,9 +333,13 @@ static int enter_state(suspend_state_t state)
if (state == PM_SUSPEND_FREEZE)
freeze_begin();
- printk(KERN_INFO "PM: Syncing filesystems ... ");
- sys_sync();
- printk("done.\n");
+#ifdef CONFIG_SUSPEND_SYNC
+ if (suspend_sync_enabled) {
+ printk(KERN_INFO "PM: Syncing filesystems ... ");
+ sys_sync();
+ printk("done.\n");
+ }
+#endif /* CONFIG_SUSPEND_SYNC */
pr_debug("PM: Preparing system for %s sleep\n", pm_states[state]);
error = suspend_prepare(state);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/22] Rewrite XIP code and add XIP support to ext4
On Thu, Jan 23, 2014 at 06:48:25PM +1100, Dave Chinner wrote: > On Wed, Jan 15, 2014 at 08:24:18PM -0500, Matthew Wilcox wrote: > > This series of patches add support for XIP to ext4. Unfortunately, > > it turns out to be necessary to rewrite the existing XIP support code > > first due to races that are unfixable in the current design. > > > > Since v4 of this patchset, I've improved the documentation, fixed a > > couple of warnings that a newer version of gcc emitted, and fixed a > > bug where we would read/write the wrong address for I/Os that were not > > aligned to PAGE_SIZE. > > > > I've dropped the PMD fault patch from this set since there are some > > places where we would need to split a PMD page and there's no way to do > > that right now. In its place, I've added a patch which attempts to add > > support for unwritten extents. I'm still in two minds about this; on the > > one hand, it's clearly a win for reads and writes. On the other hand, > > it adds a lot of complexity, and it probably isn't a win for pagefaults. > > FYI, this may just be pure coincidence, but shortly after the first > boot of a machine with this patchset on 3.13 the root *ext3* > filesystem started having problems. It now gives persistent ENOSPC > errors when there's 2.3GB of space free (on a 8GB partition), even > though e2fsck says the filesystem is clean and error free. > > Fmeh. > > Update: I've just removed the patchset, rebuilt the kernel and the > ENOSPC problem is still there. So it may be co-incidence, but given > that it is persistent something is screwed got screwed up in the > filesytem. OK, false alarm - it is co-incidence. The damn root filesystem ran out of inodes. Can you beleive that you're only allowed 600k inodes in an 8GB filesystems? Sheesh! :) Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/22] Rewrite XIP code and add XIP support to ext4
On Wed, Jan 15, 2014 at 08:24:18PM -0500, Matthew Wilcox wrote: > This series of patches add support for XIP to ext4. Unfortunately, > it turns out to be necessary to rewrite the existing XIP support code > first due to races that are unfixable in the current design. > > Since v4 of this patchset, I've improved the documentation, fixed a > couple of warnings that a newer version of gcc emitted, and fixed a > bug where we would read/write the wrong address for I/Os that were not > aligned to PAGE_SIZE. > > I've dropped the PMD fault patch from this set since there are some > places where we would need to split a PMD page and there's no way to do > that right now. In its place, I've added a patch which attempts to add > support for unwritten extents. I'm still in two minds about this; on the > one hand, it's clearly a win for reads and writes. On the other hand, > it adds a lot of complexity, and it probably isn't a win for pagefaults. FYI, this may just be pure coincidence, but shortly after the first boot of a machine with this patchset on 3.13 the root *ext3* filesystem started having problems. It now gives persistent ENOSPC errors when there's 2.3GB of space free (on a 8GB partition), even though e2fsck says the filesystem is clean and error free. Fmeh. Update: I've just removed the patchset, rebuilt the kernel and the ENOSPC problem is still there. So it may be co-incidence, but given that it is persistent something is screwed got screwed up in the filesytem. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Add at24 based EEPROMs to the eeprom_dev hardware class
On Wed, Jan 22, 2014 at 5:23 PM, Curt Brune wrote:
> During device instantiation have the at24 driver add the new device to
> the eeprom_dev hardware class. The functionality is enabled by
> CONFIG_EEPROM_CLASS.
>
> Signed-off-by: Curt Brune
> ---
> drivers/misc/eeprom/at24.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index d87f77f..07782ea 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -1,170 +1,177 @@
> /*
> * at24.c - handle most I2C EEPROMs
> *
> * Copyright (C) 2005-2007 David Brownell
> * Copyright (C) 2008 Wolfram Sang, Pengutronix
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License as published by
> * the Free Software Foundation; either version 2 of the License, or
> * (at your option) any later version.
> */
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> +#ifdef CONFIG_EEPROM_CLASS
> +#include
> +#endif
> +
> /*
> * I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
> * Differences between different vendor product lines (like Atmel AT24C or
> * MicroChip 24LC, etc) won't much matter for typical read/write access.
> * There are also I2C RAM chips, likewise interchangeable. One example
> * would be the PCF8570, which acts like a 24c02 EEPROM (256 bytes).
> *
> * However, misconfiguration can lose data. "Set 16-bit memory address"
> * to a part with 8-bit addressing will overwrite data. Writing with too
> * big a page size also loses data. And it's not safe to assume that the
> * conventional addresses 0x50..0x57 only hold eeproms; a PCF8563 RTC
> * uses 0x51, for just one example.
> *
> * Accordingly, explicit board-specific configuration data should be used
> * in almost all cases. (One partial exception is an SMBus used to access
> * "SPD" data for DRAM sticks. Those only use 24c02 EEPROMs.)
> *
> * So this driver uses "new style" I2C driver binding, expecting to be
> * told what devices exist. That may be in arch/X/mach-Y/board-Z.c or
> * similar kernel-resident tables; or, configuration data coming from
> * a bootloader.
> *
> * Other than binding model, current differences from "eeprom" driver are
> * that this one handles write access and isn't restricted to 24c02 devices.
> * It also handles larger devices (32 kbit and up) with two-byte addresses,
> * which won't work on pure SMBus systems.
> */
>
> struct at24_data {
> struct at24_platform_data chip;
> struct memory_accessor macc;
> int use_smbus;
>
> /*
> * Lock protects against activities from other Linux tasks,
> * but not from changes by other I2C masters.
> */
> struct mutex lock;
> struct bin_attribute bin;
>
> u8 *writebuf;
> unsigned write_max;
> unsigned num_addresses;
>
> +#ifdef CONFIG_EEPROM_CLASS
> + struct device *eeprom_dev;
> +#endif
> /*
> * Some chips tie up multiple I2C addresses; dummy devices reserve
> * them for us, and we'll use them with SMBus calls.
> */
> struct i2c_client *client[];
> };
>
> /*
> * This parameter is to help this driver avoid blocking other drivers out
> * of I2C for potentially troublesome amounts of time. With a 100 kHz I2C
> * clock, one 256 byte read takes about 1/43 second which is excessive;
> * but the 1/170 second it takes at 400 kHz may be quite reasonable; and
> * at 1 MHz (Fm+) a 1/430 second delay could easily be invisible.
> *
> * This value is forced to be a power of two so that writes align on pages.
> */
> static unsigned io_limit = 128;
> module_param(io_limit, uint, 0);
> MODULE_PARM_DESC(io_limit, "Maximum bytes per I/O (default 128)");
>
> /*
> * Specs often allow 5 msec for a page write, sometimes 20 msec;
> * it's important to recover from write timeouts.
> */
> static unsigned write_timeout = 25;
> module_param(write_timeout, uint, 0);
> MODULE_PARM_DESC(write_timeout, "Time (in ms) to try writes (default 25)");
>
> #define AT24_SIZE_BYTELEN 5
> #define AT24_SIZE_FLAGS 8
>
> #define AT24_BITMASK(x) (BIT(x) - 1)
>
> /* create non-zero magic value for given eeprom parameters */
> #define AT24_DEVICE_MAGIC(_len, _flags)\
> ((1 << AT24_SIZE_FLAGS | (_flags)) \
> << AT24_SIZE_BYTELEN | ilog2(_len))
>
> static const struct i2c_device_id at24_ids[] = {
> /* needs 8 addresses as A0-A2 are ignored */
> { "24c00", AT24_DEVICE_MAGIC(128 / 8, AT24_FLAG_TAKE8ADDR) },
> /* old variants can't be handled with this generic entry! */
> { "24c01", AT24_DEVICE_MAGIC(1024 / 8, 0) },
>
Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional
On 01/23/2014 12:41 PM, Len Brown wrote:
> From: Len Brown
>
> Linux suspend-to-RAM was unreliable when first developed,
> and so sys_sync() was invoked inside the kernel at the
> start of every suspend flow.
>
> Today, many devices are invoking suspend with
> high reliability and high frequency, and they don't
> want to be forced to pay for sync on every suspend.
>
> So here we make it optional.
> De-select CONFIG_PM_SLEEP_SYNC to delete the call entirely.
> or keep CONFIG_PM_SLEEP and you can now clear the
> sys/power/sleep_sync attribte to disable the sync
> from user-space.
>
> As we have had this call for a long time,
> the default remains to keep the call, and to
> invoke it on every suspend.
>
> Signed-off-by: Len Brown
> ---
> kernel/power/Kconfig | 8
> kernel/power/main.c| 33 +
> kernel/power/power.h | 1 +
> kernel/power/suspend.c | 10 +++---
> 4 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 2fac9cc..d2927ce 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -102,6 +102,14 @@ config PM_SLEEP_SMP
> depends on PM_SLEEP
> select HOTPLUG_CPU
>
> +config PM_SLEEP_SYNC
How about naming it as PM_SLEEP_FS_SYNC (and similarly in the sysfs files
and variable names as well). Just to avoid confusion with "synchronous/async".
Regards,
Srivatsa S. Bhat
> + bool "Suspend to RAM starts with in-kernel call to sync()"
> + default y
> + depends on PM_SLEEP
> + ---help---
> + Build a call to sync() into the Linux kernel suspend to RAM flow.
> + The sync can still be skipped by clearing /sys/power/sleep_sync.
> +
> config PM_AUTOSLEEP
> bool "Opportunistic sleep"
> depends on PM_SLEEP
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index 1d1bf63..1102871 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -71,6 +71,36 @@ static ssize_t pm_async_store(struct kobject *kobj, struct
> kobj_attribute *attr,
>
> power_attr(pm_async);
>
> +#ifdef CONFIG_PM_SLEEP_SYNC
> +
> +/* If set, sync file systems at start of suspend flow */
> +int pm_sleep_sync_enabled = 1;
> +
> +static ssize_t pm_sleep_sync_show(struct kobject *kobj, struct
> kobj_attribute *attr,
> + char *buf)
> +{
> + return sprintf(buf, "%d\n", pm_sleep_sync_enabled);
> +}
> +
> +static ssize_t pm_sleep_sync_store(struct kobject *kobj, struct
> kobj_attribute *attr,
> + const char *buf, size_t n)
> +{
> + unsigned long val;
> +
> + if (kstrtoul(buf, 10, &val))
> + return -EINVAL;
> +
> + if (val > 1)
> + return -EINVAL;
> +
> + pm_sleep_sync_enabled = val;
> + return n;
> +}
> +
> +power_attr(pm_sleep_sync);
> +
> +#endif /* CONFIG_PM_SLEEP_SYNC */
> +
> #ifdef CONFIG_PM_DEBUG
> int pm_test_level = TEST_NONE;
>
> @@ -592,6 +622,9 @@ static struct attribute * g[] = {
> #ifdef CONFIG_PM_SLEEP
> &pm_async_attr.attr,
> &wakeup_count_attr.attr,
> +#ifdef CONFIG_PM_SLEEP_SYNC
> + &pm_sleep_sync_attr.attr,
> +#endif
> #ifdef CONFIG_PM_AUTOSLEEP
> &autosleep_attr.attr,
> #endif
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 7d4b7ff..dca60a7 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -200,6 +200,7 @@ static inline void suspend_test_finish(const char *label)
> {}
> #ifdef CONFIG_PM_SLEEP
> /* kernel/power/main.c */
> extern int pm_notifier_call_chain(unsigned long val);
> +extern int pm_sleep_sync_enabled;
> #endif
>
> #ifdef CONFIG_HIGHMEM
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 62ee437..2fb2f51 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -333,9 +333,13 @@ static int enter_state(suspend_state_t state)
> if (state == PM_SUSPEND_FREEZE)
> freeze_begin();
>
> - printk(KERN_INFO "PM: Syncing filesystems ... ");
> - sys_sync();
> - printk("done.\n");
> +#ifdef CONFIG_PM_SLEEP_SYNC
> + if (pm_sleep_sync_enabled) {
> + printk(KERN_INFO "PM: Syncing filesystems ... ");
> + sys_sync();
> + printk("done.\n");
> + }
> +#endif /* CONFIG_PM_SLEEP_SYNC */
>
> pr_debug("PM: Preparing system for %s sleep\n", pm_states[state]);
> error = suspend_prepare(state);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional
> > + depends on PM_SLEEP > > this is actually a suspend specific feature, and it should depends on > SUSPEND instead? yup, will update. thanks, -Len
Re: [PATCH 5/5] ARM: tegra: cpuidle: use firmware call for power down
On Thu, Jan 23, 2014 at 5:45 AM, Stephen Warren wrote: > On 01/21/2014 03:10 AM, Alexandre Courbot wrote: >> Invoke the do_idle() firmware call before suspending a CPU so that the >> underlying firmware (if any) can take necessary action. > >> diff --git a/arch/arm/mach-tegra/cpuidle-tegra114.c >> b/arch/arm/mach-tegra/cpuidle-tegra114.c > >> @@ -45,6 +46,8 @@ static int tegra114_idle_power_down(struct cpuidle_device >> *dev, >> >> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &dev->cpu); >> >> + call_firmware_op(do_idle); >> + >> cpu_suspend(0, tegra30_sleep_cpu_secondary_finish); >> >> clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &dev->cpu); > > Don't you need to have the kernel also *not* do something when entering > idle; doesn't the FW op replace some of the register writes that the > kernel would otherwise be doing? It seems like the operation is actually to inform the firmware that we are going to suspend the CPU. Downstream kernel also uses it that way. But you are right in that we should expect do_idle() to actually perform the suspend operation. Maybe a prepare_idle() operation should be added to the firmware interface for this purpose? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: at91: use locked variant of irq_set_handler
On Tue, Jan 21, 2014 at 4:55 PM, Nicolas Ferre wrote: > When setting the gpio irq type, use the __irq_set_handler_locked() > variant instead of the irq_set_handler() to prevent false > spinlock recursion warning. > > Signed-off-by: Nicolas Ferre > Cc: stable # v3.12 Patch applied for fixes. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] ARM: trusted_foundations: implement do_idle()
On Thu, Jan 23, 2014 at 5:43 AM, Stephen Warren wrote: > On 01/21/2014 03:10 AM, Alexandre Courbot wrote: >> Support the do_idle() firmware call, which is necessary to properly >> support cpuidle. > >> diff --git a/arch/arm/firmware/trusted_foundations.c >> b/arch/arm/firmware/trusted_foundations.c > >> +#define TF_CPU_PM 0xfffc >> +#define TF_CPU_PM_LP0 0xffe3 >> +#define TF_CPU_PM_LP1 0xffe6 >> +#define TF_CPU_PM_LP1_NO_MC_CLK 0xffe5 >> +#define TF_CPU_PM_LP2 0xffe4 >> +#define TF_CPU_PM_LP2_NOFLUSH_L2 0xffe7 > > Hmm. This must be Tegra-specific, not generic to any TF client, since > aren't the names of the suspend states (LP0, LP1, LP2) entirely specific > to Tegra? The names are negligence on my part, actually. I arbitrarily named them that way without thinking this was Tegra-only denomination. The downstream kernel does not even use these, they hardcode the values directly. Will fix that, thanks for spotting it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 2/2] pwm: imx: support polarity inversion
Hi,
Sascha Hauer wrote:
> On Thu, Jan 16, 2014 at 09:06:25AM +0100, Lothar Waßmann wrote:
> > The i.MX PWM controller supports inverting the polarity of the PWM
> > output. Make this feature available in the pxm-imx driver.
> >
> > Signed-off-by: Lothar Waßmann
> > ---
> > Documentation/devicetree/bindings/pwm/imx-pwm.txt |5 +-
> > drivers/pwm/pwm-imx.c | 42
> > +
> > 2 files changed, 45 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > index b50d7a6d..d0b04b5 100644
> > --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
> > @@ -3,8 +3,9 @@ Freescale i.MX PWM controller
> > Required properties:
> > - compatible: should be "fsl,-pwm"
> > - reg: physical base address and length of the controller's registers
> > -- #pwm-cells: should be 2. See pwm.txt in this directory for a description
> > of
> > - the cells format.
> > +- #pwm-cells: may be 2 for backwards compatibility or 3 to support
> > + switching the output polarity. See pwm.txt in this directory for a
> > + description of the cells format.
> > - interrupts: The interrupt for the pwm controller
> >
> > Example:
> > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c
> > index 3b00a82..05461bb 100644
> > --- a/drivers/pwm/pwm-imx.c
> > +++ b/drivers/pwm/pwm-imx.c
> > @@ -36,6 +36,7 @@
> > #define MX3_PWMCR_DOZEEN (1 << 24)
> > #define MX3_PWMCR_WAITEN (1 << 23)
> > #define MX3_PWMCR_DBGEN(1 << 22)
> > +#define MX3_PWMCR_POUTC(1 << 18)
> > #define MX3_PWMCR_CLKSRC_IPG_HIGH (2 << 16)
> > #define MX3_PWMCR_CLKSRC_IPG (1 << 16)
> > #define MX3_PWMCR_EN (1 << 0)
> > @@ -138,6 +139,9 @@ static int imx_pwm_config_v2(struct pwm_chip *chip,
> > if (test_bit(PWMF_ENABLED, &pwm->flags))
> > cr |= MX3_PWMCR_EN;
> >
> > + if (pwm->polarity == PWM_POLARITY_INVERSED)
> > + cr |= MX3_PWMCR_POUTC;
> > +
> > writel(cr, imx->mmio_base + MX3_PWMCR);
> >
> > return 0;
> > @@ -155,6 +159,11 @@ static void imx_pwm_set_enable_v2(struct pwm_chip
> > *chip, bool enable)
> > else
> > val &= ~MX3_PWMCR_EN;
> >
> > + if (chip->pwms[0].polarity == PWM_POLARITY_INVERSED)
> > + val |= MX3_PWMCR_POUTC;
> > + else
> > + val &= ~MX3_PWMCR_POUTC;
> > +
> > writel(val, imx->mmio_base + MX3_PWMCR);
> > }
> >
> > @@ -198,6 +207,17 @@ static void imx_pwm_disable(struct pwm_chip *chip,
> > struct pwm_device *pwm)
> > clk_disable_unprepare(imx->clk_per);
> > }
> >
> > +static int imx_pwm_set_polarity(struct pwm_chip *chip, struct pwm_device
> > *pwm,
> > + enum pwm_polarity polarity)
> > +{
> > + struct imx_chip *imx = to_imx_chip(chip);
> > +
> > + dev_dbg(imx->chip.dev, "%s: polarity set to %s\n", __func__,
> > + polarity == PWM_POLARITY_INVERSED ? "inverted" : "normal");
> > +
> > + return 0;
> > +}
> > +
> > static struct pwm_ops imx_pwm_ops = {
> > .enable = imx_pwm_enable,
> > .disable = imx_pwm_disable,
> > @@ -209,6 +229,7 @@ struct imx_pwm_data {
> > int (*config)(struct pwm_chip *chip,
> > struct pwm_device *pwm, int duty_ns, int period_ns);
> > void (*set_enable)(struct pwm_chip *chip, bool enable);
> > + unsigned output_polarity:1;
> > };
> >
> > static struct imx_pwm_data imx_pwm_data_v1 = {
> > @@ -219,6 +240,7 @@ static struct imx_pwm_data imx_pwm_data_v1 = {
> > static struct imx_pwm_data imx_pwm_data_v2 = {
> > .config = imx_pwm_config_v2,
> > .set_enable = imx_pwm_set_enable_v2,
> > + .output_polarity = 1,
> > };
> >
> > static const struct of_device_id imx_pwm_dt_ids[] = {
> > @@ -271,6 +293,26 @@ static int imx_pwm_probe(struct platform_device *pdev)
> > return PTR_ERR(imx->mmio_base);
> >
> > data = of_id->data;
> > + if (data->output_polarity) {
> > + const struct device_node *np = pdev->dev.of_node;
> > + u32 num_cells;
> > +
> > + dev_dbg(&pdev->dev, "PWM supports output inversion\n");
> > + ret = of_property_read_u32(np, "#pwm-cells", &num_cells);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "missing property '#pwm-cells'\n");
> > + return ret;
> > + }
> > + if (num_cells == 3) {
> > + imx_pwm_ops.set_polarity = imx_pwm_set_polarity;
> > + imx->chip.of_xlate = of_pwm_xlate_with_flags;
> > + } else if (num_cells != 2) {
> > + dev_err(&pdev->dev, "'#pwm-cells' must be <2> or
> > <3>\n");
> > + return -EINVAL;
> > + }
> > + imx->chip.of_pwm_n_cells = num_cells;
> > + }
>
> Can't this be done in the PWM
Re: [PATCH 3/5] ARM: firmware: enable Trusted Foundations by default
On Thu, Jan 23, 2014 at 5:42 AM, Stephen Warren wrote: > On 01/21/2014 03:10 AM, Alexandre Courbot wrote: >> As discussed previously (https://lkml.org/lkml/2013/11/26/289), enable >> Trusted Foundation support by default since it already depends on a >> supporting architecture being selected. >> >> Doing so allows us to remove it from tegra_defconfig. > >> arch/arm/configs/tegra_defconfig | 1 - >> arch/arm/firmware/Kconfig| 1 + > > Can we split out the defconfig and code changes into separate patches? > They need to go through seperate branches, possibly even separate repos. > > The defconfig change might not even be necessary; at some point I'll > just rebuild it via "make tegra_defconfig; make savedefconfig" on top of > some linux-next that includes the Kconfig change, and it'll happen > automatically. Still, I guess there's no harm explicitly sending the patch. If we can do without the defconfig change then I will just omit it in the next version - I don't like sending too many oneliners. :P -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] iMX gpio: Allow reading back of pin status if configured as gpio output
On Fri, Jan 17, 2014 at 11:27 PM, Waibel Georg wrote: > Seems there is no need for my patch at all. I'm holding this off until you've made up your mind about whether it's needed or not... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] regulator: s5m8767: Document new bindings for Buck9 GPIO control
On Wed, 2014-01-22 at 19:49 +, Mark Brown wrote: > On Wed, Jan 22, 2014 at 05:07:28PM +0100, Krzysztof Kozlowski wrote: > > Add documentation for new bindings for controlling (enable/disable) the > > Buck9 Converter by GPIO (BUCK9EN). > > Your CC list for this is *very* large... Hmmm... The get_maintainers produces such long list for any change in Documentation/devicetree/bindings... I'll stop using it for this. > > > + - s5m8767,pmic-ext-control-enable: regulator can be enabled/disabled > > + by GPIO (valid only for buck9). > > + - s5m8767,pmic-ext-control-gpio: GPIO specifier for one GPIO > > + controlling this regulator (valid only for buck9). > > + This property is required when > > 's5m8767,pmic-ext-control-enable' is specified. > > In what situation might the GPIO be present but not usable - can't we > just use the presence of the GPIO property? Also GPIO properties are > supposed to be always "-gpios". Remove the "s5m8767,pmic-ext-control-enable" and use only "s5m8767,pmic-ext-control-gpios"? Sure, that makes sense. Thanks for idea. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] gpio: intel-mid: comments cleanup
On Fri, Jan 17, 2014 at 4:30 PM, David Cohen wrote: > This is a simple cleanup on gpio-intel-mid.c's header comments. > > Signed-off-by: David Cohen Applied, but I changed it like this: > - * Copyright (c) 2008, 2009, 2013, Intel Corporation. > + * Copyright (c) 2014 Intel Corporation. To-> Copyright (c) 2008-2014 Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] ARM:STi: STiH415: Add interrupt support for pin controller
On Thu, Jan 16, 2014 at 4:37 PM, wrote: > From: Srinivas Kandagatla > > This patch adds interrupt support for STiH415 pin controllers. > > Signed-off-by: Srinivas Kandagatla Acked-by: Linus Walleij Merge this through ARM SoC. > + reg = <0xfe61f080 0x4>; > + reg-names = "irqmux"; Aha so that is how it looks when you handle the separate mux reg, well I can't think of anything better and this works fine for me. The alternative would be to have a syscon thing using regmap such as drivers/mfd/syscon.c but I really cannot decide between these two design patterns for odd registers. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How to identify different ip tunnels
Hi, Maintainers We want to identify different ip tunnels. For example, we use “ip tunnel add xxx” command in linux to create an ipv4/6 tunnel interface,then,we can receive a RTM_NEWLINK message from linux for the new tunnel interface. We will parse the struct ifinfomsg message and get the ifi->ifi_type attribute. We need to do somethings depend on the tunnel type here. I checked the linux source code and list all the tunnel types here: #define ARPHRD_TUNNEL 768 /* IPIP tunnel */ #define ARPHRD_TUNNEL6 769 /* IP6IP6 tunnel */ #define ARPHRD_SIT 776 /* sit0 device - IPv6-in-IPv4 */ #define ARPHRD_IPGRE 778 /* GRE over IP */ It means that the linux will report the new link for any ipv4/6 tunnel interface with type only within these four types. However, We need more tunnel types for ipv4/6 tunnel. For example, 4IN4/6IN4/6TO4/GRE/ISATAP for ipv4 tunnel and 4IN6/6IN6/IPIN6 for ipv6 tunnel. Here are the result that we have got: Actual Tunnel type ifi->ifi_type 4IN4 768 GRE4 778 6IN4/6TO4/ISATAP 776 4IN6/6IN6/IPIN6 769 So, we can NOT distinguish the actual tunnel type via ifi_type attribute except the GRE4 and 4IN4 tunnel. However we need the actual type. That is our question. BTW, for the 6IN4 and 6TO4 tunnel, Can we distinguish them before the interface ip address configured? Because we need to do different things for them when we received the new link message and the tunnel has NOT any ip address in this time. Best Regards! Zhu Yanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] ARM:STi: STiH416: Add interrupt support for pin controller
On Thu, Jan 16, 2014 at 4:37 PM, wrote: > From: Srinivas Kandagatla > > This patch adds interrupt support for STiH416 pin controllers. > > Signed-off-by: Srinivas Kandagatla Acked-by: Linus Walleij Please merge this through the ARM SoC tree with the rest of your device tree stuff. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] pinctrl: st: Add software edge trigger interrupt support.
On Thu, Jan 16, 2014 at 4:37 PM, wrote: > ST pin controller does not have hardware support for detecting edge > triggered interrupts, It only has level triggering support. > This patch attempts to fake up edge triggers from hw level trigger > support in software. (...) > +/* > + * Edge triggers are not supported at hardware level, it is supported by > + * software by exploiting the level trigger support in hardware. > + * Software uses a virtual register (EDGE_CONF) for edge trigger > configuration > + * of each gpio pin in a GPIO bank. (...) > +/* > + * As edge triggers are not supported at hardware level, it is supported by > + * software by exploiting the level trigger support in hardware. (...) All this is quite hard to understand. Maybe it's just because it's hard overall. Edge triggers are not supported by hardware so we use the hardware edge trigger support? That is a bit oxymoronic... > + * Steps for detection raising edge interrupt in software. > + * > + * Step 1: CONFIGURE pin to detect level LOW interrupts. > + * > + * Step 2: DETECT level LOW interrupt and in irqmux/gpio bank interrupt > handler, > + * if the value of pin is low, then CONFIGURE pin for level HIGH interrupt. > + * IGNORE calling the actual interrupt handler for the pin at this stage. > + * > + * Step 3: DETECT level HIGH interrupt and in irqmux/gpio-bank interrupt > handler > + * if the value of pin is HIGH, CONFIGURE pin for level LOW interrupt and > then > + * DISPATCH the interrupt to the interrupt handler of the pin. But I do understand this, that's VERY clever and may be something that can be exploited on other hardware as well some day. So patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] suspend: make sync() on suspend-to-RAM optional
On Thu, 2014-01-23 at 02:11 -0500, Len Brown wrote:
> From: Len Brown
>
> Linux suspend-to-RAM was unreliable when first developed,
> and so sys_sync() was invoked inside the kernel at the
> start of every suspend flow.
>
> Today, many devices are invoking suspend with
> high reliability and high frequency, and they don't
> want to be forced to pay for sync on every suspend.
>
> So here we make it optional.
> De-select CONFIG_PM_SLEEP_SYNC to delete the call entirely.
> or keep CONFIG_PM_SLEEP and you can now clear the
> sys/power/sleep_sync attribte to disable the sync
> from user-space.
>
> As we have had this call for a long time,
> the default remains to keep the call, and to
> invoke it on every suspend.
>
> Signed-off-by: Len Brown
> ---
> kernel/power/Kconfig | 8
> kernel/power/main.c| 33 +
> kernel/power/power.h | 1 +
> kernel/power/suspend.c | 10 +++---
> 4 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 2fac9cc..d2927ce 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -102,6 +102,14 @@ config PM_SLEEP_SMP
> depends on PM_SLEEP
> select HOTPLUG_CPU
>
> +config PM_SLEEP_SYNC
> + bool "Suspend to RAM starts with in-kernel call to sync()"
> + default y
> + depends on PM_SLEEP
this is actually a suspend specific feature, and it should depends on
SUSPEND instead?
thanks,
rui
> + ---help---
> + Build a call to sync() into the Linux kernel suspend to RAM flow.
> + The sync can still be skipped by clearing /sys/power/sleep_sync.
> +
> config PM_AUTOSLEEP
> bool "Opportunistic sleep"
> depends on PM_SLEEP
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index 1d1bf63..1102871 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -71,6 +71,36 @@ static ssize_t pm_async_store(struct kobject *kobj, struct
> kobj_attribute *attr,
>
> power_attr(pm_async);
>
> +#ifdef CONFIG_PM_SLEEP_SYNC
> +
> +/* If set, sync file systems at start of suspend flow */
> +int pm_sleep_sync_enabled = 1;
> +
> +static ssize_t pm_sleep_sync_show(struct kobject *kobj, struct
> kobj_attribute *attr,
> + char *buf)
> +{
> + return sprintf(buf, "%d\n", pm_sleep_sync_enabled);
> +}
> +
> +static ssize_t pm_sleep_sync_store(struct kobject *kobj, struct
> kobj_attribute *attr,
> + const char *buf, size_t n)
> +{
> + unsigned long val;
> +
> + if (kstrtoul(buf, 10, &val))
> + return -EINVAL;
> +
> + if (val > 1)
> + return -EINVAL;
> +
> + pm_sleep_sync_enabled = val;
> + return n;
> +}
> +
> +power_attr(pm_sleep_sync);
> +
> +#endif /* CONFIG_PM_SLEEP_SYNC */
> +
> #ifdef CONFIG_PM_DEBUG
> int pm_test_level = TEST_NONE;
>
> @@ -592,6 +622,9 @@ static struct attribute * g[] = {
> #ifdef CONFIG_PM_SLEEP
> &pm_async_attr.attr,
> &wakeup_count_attr.attr,
> +#ifdef CONFIG_PM_SLEEP_SYNC
> + &pm_sleep_sync_attr.attr,
> +#endif
> #ifdef CONFIG_PM_AUTOSLEEP
> &autosleep_attr.attr,
> #endif
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 7d4b7ff..dca60a7 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -200,6 +200,7 @@ static inline void suspend_test_finish(const char *label)
> {}
> #ifdef CONFIG_PM_SLEEP
> /* kernel/power/main.c */
> extern int pm_notifier_call_chain(unsigned long val);
> +extern int pm_sleep_sync_enabled;
> #endif
>
> #ifdef CONFIG_HIGHMEM
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index 62ee437..2fb2f51 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -333,9 +333,13 @@ static int enter_state(suspend_state_t state)
> if (state == PM_SUSPEND_FREEZE)
> freeze_begin();
>
> - printk(KERN_INFO "PM: Syncing filesystems ... ");
> - sys_sync();
> - printk("done.\n");
> +#ifdef CONFIG_PM_SLEEP_SYNC
> + if (pm_sleep_sync_enabled) {
> + printk(KERN_INFO "PM: Syncing filesystems ... ");
> + sys_sync();
> + printk("done.\n");
> + }
> +#endif /* CONFIG_PM_SLEEP_SYNC */
>
> pr_debug("PM: Preparing system for %s sleep\n", pm_states[state]);
> error = suspend_prepare(state);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 67651] Bisected: Lots of fragmented mmaps cause gimp to fail in 3.12 after exceeding vm_max_map_count
On Wed, Jan 22, 2014 at 11:52:15AM -0800, Andrew Morton wrote: > On Wed, 22 Jan 2014 19:08:16 + Mel Gorman wrote: > > > X-related junk is there was because I was using a headless server and > > xinit directly to launch gimp to reproduce the bug. > > I've never done this. Can you share the magic recipe for running an X > app in this way? > The relevant part of the test script is # Build a wrapper script to launch gimp cat > gimp-launch.sh << EOF /usr/bin/gimp -i -b "(mmtests-open-image \"$FILENAME\")" -b "(gimp-quit 0)" > $LOGDIR_RESULTS/gimp-out.1 2>&1 echo \$? > gimp-exit-code EOF chmod u+x gimp-launch.sh $TIME_CMD xinit ./gimp-launch.sh 2> $LOGDIR_RESULTS/time.1 RETVAL=`cat gimp-exit-code` It's clumsy because the application would start with no window manager and looking at it again, it probably was not even necessary because of the -i switch in gimp. Previously when I needed to automate an X app I configured the machine to login automatically, exported the DISPLAY variable in the test script and used wmctrl to detect if an application had a window displayed yet. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH Resend 2/8] ASoC: simple-card: fix __asoc_simple_card_dai_init
> > diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-
> card.c
> > index 6443c87..3b8c9a2 100644
> > --- a/sound/soc/generic/simple-card.c
> > +++ b/sound/soc/generic/simple-card.c
> > @@ -31,16 +31,21 @@ static int __asoc_simple_card_dai_init(struct
> snd_soc_dai *dai,
> >
> > daifmt |= set->fmt;
> >
> > - if (daifmt)
> > + if (daifmt) {
> > ret = snd_soc_dai_set_fmt(dai, daifmt);
> > -
> > - if (ret == -ENOTSUPP) {
> > - dev_dbg(dai->dev, "ASoC: set_fmt is not supported\n");
> > - ret = 0;
> > + if (ret && ret != -ENOTSUPP) {
> > + dev_err(dai->dev, "simple-card: set_fmt error\n");
> > + return ret;
> > + }
> > }
> >
> > - if (!ret && set->sysclk)
> > + if (set->sysclk) {
> > ret = snd_soc_dai_set_sysclk(dai, 0, set->sysclk, 0);
> > + if (ret && ret != -ENOTSUPP) {
> > + dev_err(dai->dev, "simple-card: set_sysclk error\n");
> > + return ret;
> > + }
> > + }
> >
> > return ret;
>
> Sorry: you must return 0 here
>
Yes, the ret maybe -ENOTSUPP.
I will revise it.
Thanks,
Best Regards,
Xiubo
Re: [PATCH v2 1/4] pinctrl: st: Add Interrupt support.
On Thu, Jan 16, 2014 at 4:36 PM, wrote: > From: Srinivas Kandagatla > > This patch add interrupt support to the pincontroller driver. > > ST Pincontroller GPIO bank can have one of the two possible types of > interrupt-wirings. > > First type is via irqmux, single interrupt is used by multiple gpio > banks. This reduces number of overall interrupts numbers required. All > these banks belong to a single pincontroller. > _ > | |> [gpio-bank (n)] > | |> [gpio-bank (n + 1)] > [irqN]-- | irq-mux |> [gpio-bank (n + 2)] > | |> [gpio-bank (... )] > |_|> [gpio-bank (n + 7)] > > Second type has a dedicated interrupt per gpio bank. > > [irqN]> [gpio-bank (n)] > > Signed-off-by: Srinivas Kandagatla I've applied this patch so that it won't just sit idle. Besides you've done a real good job on it Srinivas. It'll be for v3.15 though and I'm still waiting to see if the device tree people say something about it. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] suspend: make sync() on suspend-to-RAM optional
From: Len Brown
Linux suspend-to-RAM was unreliable when first developed,
and so sys_sync() was invoked inside the kernel at the
start of every suspend flow.
Today, many devices are invoking suspend with
high reliability and high frequency, and they don't
want to be forced to pay for sync on every suspend.
So here we make it optional.
De-select CONFIG_PM_SLEEP_SYNC to delete the call entirely.
or keep CONFIG_PM_SLEEP and you can now clear the
sys/power/sleep_sync attribte to disable the sync
from user-space.
As we have had this call for a long time,
the default remains to keep the call, and to
invoke it on every suspend.
Signed-off-by: Len Brown
---
kernel/power/Kconfig | 8
kernel/power/main.c| 33 +
kernel/power/power.h | 1 +
kernel/power/suspend.c | 10 +++---
4 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 2fac9cc..d2927ce 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -102,6 +102,14 @@ config PM_SLEEP_SMP
depends on PM_SLEEP
select HOTPLUG_CPU
+config PM_SLEEP_SYNC
+ bool "Suspend to RAM starts with in-kernel call to sync()"
+ default y
+ depends on PM_SLEEP
+ ---help---
+ Build a call to sync() into the Linux kernel suspend to RAM flow.
+ The sync can still be skipped by clearing /sys/power/sleep_sync.
+
config PM_AUTOSLEEP
bool "Opportunistic sleep"
depends on PM_SLEEP
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 1d1bf63..1102871 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -71,6 +71,36 @@ static ssize_t pm_async_store(struct kobject *kobj, struct
kobj_attribute *attr,
power_attr(pm_async);
+#ifdef CONFIG_PM_SLEEP_SYNC
+
+/* If set, sync file systems at start of suspend flow */
+int pm_sleep_sync_enabled = 1;
+
+static ssize_t pm_sleep_sync_show(struct kobject *kobj, struct kobj_attribute
*attr,
+char *buf)
+{
+ return sprintf(buf, "%d\n", pm_sleep_sync_enabled);
+}
+
+static ssize_t pm_sleep_sync_store(struct kobject *kobj, struct kobj_attribute
*attr,
+ const char *buf, size_t n)
+{
+ unsigned long val;
+
+ if (kstrtoul(buf, 10, &val))
+ return -EINVAL;
+
+ if (val > 1)
+ return -EINVAL;
+
+ pm_sleep_sync_enabled = val;
+ return n;
+}
+
+power_attr(pm_sleep_sync);
+
+#endif /* CONFIG_PM_SLEEP_SYNC */
+
#ifdef CONFIG_PM_DEBUG
int pm_test_level = TEST_NONE;
@@ -592,6 +622,9 @@ static struct attribute * g[] = {
#ifdef CONFIG_PM_SLEEP
&pm_async_attr.attr,
&wakeup_count_attr.attr,
+#ifdef CONFIG_PM_SLEEP_SYNC
+ &pm_sleep_sync_attr.attr,
+#endif
#ifdef CONFIG_PM_AUTOSLEEP
&autosleep_attr.attr,
#endif
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 7d4b7ff..dca60a7 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -200,6 +200,7 @@ static inline void suspend_test_finish(const char *label) {}
#ifdef CONFIG_PM_SLEEP
/* kernel/power/main.c */
extern int pm_notifier_call_chain(unsigned long val);
+extern int pm_sleep_sync_enabled;
#endif
#ifdef CONFIG_HIGHMEM
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 62ee437..2fb2f51 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -333,9 +333,13 @@ static int enter_state(suspend_state_t state)
if (state == PM_SUSPEND_FREEZE)
freeze_begin();
- printk(KERN_INFO "PM: Syncing filesystems ... ");
- sys_sync();
- printk("done.\n");
+#ifdef CONFIG_PM_SLEEP_SYNC
+ if (pm_sleep_sync_enabled) {
+ printk(KERN_INFO "PM: Syncing filesystems ... ");
+ sys_sync();
+ printk("done.\n");
+ }
+#endif /* CONFIG_PM_SLEEP_SYNC */
pr_debug("PM: Preparing system for %s sleep\n", pm_states[state]);
error = suspend_prepare(state);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH Resend 2/8] ASoC: simple-card: fix __asoc_simple_card_dai_init
On Thu, 23 Jan 2014 13:02:44 +0800
Xiubo Li wrote:
> If the CPU/CODEC DAI set_sysclk() is not support, the -ENOTSUPP will returnd.
> Here do the check like set_fmt().
>
> Signed-off-by: Xiubo Li
> ---
>
>
>
> The VF610 Tower and VF610 LS1 platforms' ESAI and SPDIF will depend on this
> patch too.
>
>
>
>
> sound/soc/generic/simple-card.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
> index 6443c87..3b8c9a2 100644
> --- a/sound/soc/generic/simple-card.c
> +++ b/sound/soc/generic/simple-card.c
> @@ -31,16 +31,21 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai
> *dai,
>
> daifmt |= set->fmt;
>
> - if (daifmt)
> + if (daifmt) {
> ret = snd_soc_dai_set_fmt(dai, daifmt);
> -
> - if (ret == -ENOTSUPP) {
> - dev_dbg(dai->dev, "ASoC: set_fmt is not supported\n");
> - ret = 0;
> + if (ret && ret != -ENOTSUPP) {
> + dev_err(dai->dev, "simple-card: set_fmt error\n");
> + return ret;
> + }
> }
>
> - if (!ret && set->sysclk)
> + if (set->sysclk) {
> ret = snd_soc_dai_set_sysclk(dai, 0, set->sysclk, 0);
> + if (ret && ret != -ENOTSUPP) {
> + dev_err(dai->dev, "simple-card: set_sysclk error\n");
> + return ret;
> + }
> + }
>
> return ret;
Sorry: you must return 0 here
> }
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sched: add statistic for rq->max_idle_balance_cost
On 01/23/2014 02:10 AM, Jason Low wrote:
>>> > > P64(avg_idle);
>>> > > + P64(max_idle_balance_cost);
>>> > > #endif
>>> > > P(ttwu_count);
>> >
>> > Not also the per-sd value in sd_alloc_ctl_domain_table() ?
> Yeah, tracking the sd->max_newidle_lb_cost can also be useful.
>
>
Thanks for suggestion!
I thought the sd->max_newidle_lb_cost keep changing. But yes, it's
still meaningful.
BTW, in the pandaboard ES, sd balance cost is about 1~2ms.
---
>From d37e712b623fb6776d0caba8e4bd06460e26b84e Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Tue, 21 Jan 2014 13:28:55 +0800
Subject: [PATCH] sched: add statistic for newidle load balance cost
Tracking rq->max_idle_balance_cost and sd->max_newidle_lb_cost
It's useful to track these values in debug mode.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 7 +--
kernel/sched/debug.c | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c3f3824..a046bc3 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4293,7 +4293,7 @@ set_table_entry(struct ctl_table *entry,
static struct ctl_table *
sd_alloc_ctl_domain_table(struct sched_domain *sd)
{
- struct ctl_table *table = sd_alloc_ctl_entry(8);
+ struct ctl_table *table = sd_alloc_ctl_entry(9);
if (table == NULL)
return NULL;
@@ -4313,7 +4313,10 @@ sd_alloc_ctl_domain_table(struct sched_domain *sd)
sizeof(int), 0644, proc_dointvec_minmax);
set_table_entry(&table[6], "name", sd->name,
CORENAME_MAX_SIZE, 0444, proc_dostring);
- /* &table[7] is terminator */
+ set_table_entry(&table[7], "max_newidle_lb_cost",
+ &sd->max_newidle_lb_cost,
+ sizeof(long), 0644, proc_doulongvec_minmax);
+ /* &table[8] is terminator */
return table;
}
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 1e43e70..9ecd861 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -315,6 +315,7 @@ do {
\
P(sched_goidle);
#ifdef CONFIG_SMP
P64(avg_idle);
+ P64(max_idle_balance_cost);
#endif
P(ttwu_count);
--
1.8.1.2
--
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: vt8500: Update maintained files for arch/vt8500
Removed maintainership of the ehci-platform.c and uhci-platform.c drivers. These drivers are not solely used by arch-vt8500 anymore, and are captured under Alan Stern's 'USB EHCI DRIVER' and 'USB UHCI DRIVER' wildcards. Add maintainership for the VT8500's clock, irq and pinctrl drivers which were added/migrated quite some time ago. Signed-off-by: Tony Prisk --- MAINTAINERS |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 6a6e4ac..ac26897 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1341,14 +1341,15 @@ M: Tony Prisk L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm/mach-vt8500/ +F: drivers/clk/clk-vt8500.c F: drivers/clocksource/vt8500_timer.c F: drivers/i2c/busses/i2c-wmt.c +F: drivers/irqchip/irq-vt8500.c F: drivers/mmc/host/wmt-sdmmc.c +F: drivers/pinctrl/vt8500/ F: drivers/pwm/pwm-vt8500.c F: drivers/rtc/rtc-vt8500.c F: drivers/tty/serial/vt8500_serial.c -F: drivers/usb/host/ehci-platform.c -F: drivers/usb/host/uhci-platform.c F: drivers/video/vt8500lcdfb.* F: drivers/video/wm8505fb* F: drivers/video/wmt_ge_rops.* -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] serial: vt8500: Add missing binding document for arch-vt8500 serial driver.
The binding document for the vt8500/wm8xxx SoC UART driver is missing.
This patch adds the binding document.
Signed-off-by: Tony Prisk
---
.../devicetree/bindings/serial/vt8500-uart.txt | 26
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/vt8500-uart.txt
diff --git a/Documentation/devicetree/bindings/serial/vt8500-uart.txt
b/Documentation/devicetree/bindings/serial/vt8500-uart.txt
new file mode 100644
index 000..795c393
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/vt8500-uart.txt
@@ -0,0 +1,26 @@
+* VIA VT8500 and WonderMedia WM8xxx UART Controller
+
+Required properties:
+- compatible: should be "via,vt8500-uart"
+
+- reg: base physical address of the controller and length of memory mapped
+ region.
+
+- interrupts: hardware interrupt number
+
+- clocks: shall be the input parent clock phandle for the clock. This should
+ be the 24Mhz reference clock.
+
+Aliases may be defined to ensure the correct ordering of the uarts.
+
+Example:
+ aliases {
+ serial0 = &uart0;
+ };
+
+ uart0: serial@d820 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd820 0x1040>;
+ interrupts = <32>;
+ clocks = <&clkuart0>;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] vt8500: pinctrl: Change devicetree data parsing
Due to an assumption in the VT8500 pinctrl driver, the value passed
from devicetree for 'wm,pull' was not explicitly translated before
being passed to pinconf.
With changes to 'enum pin_config_param', PIN_CONFIG_BIAS_PULL_(UP/DOWN)
no longer map 1-to-1 with the expected values in devicetree.
This patch adds a small translation between the devicetree values (0..2)
and the enum pin_config_param equivalent values.
Signed-off-by: Tony Prisk
---
drivers/pinctrl/vt8500/pinctrl-wmt.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c
b/drivers/pinctrl/vt8500/pinctrl-wmt.c
index 39aec08..fa4fdbd 100644
--- a/drivers/pinctrl/vt8500/pinctrl-wmt.c
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.c
@@ -276,6 +276,17 @@ static int wmt_pctl_dt_node_to_map_pull(struct
wmt_pinctrl_data *data,
if (!configs)
return -ENOMEM;
+ switch (pull) {
+ case 0:
+ pull = PIN_CONFIG_BIAS_DISABLE;
+ break;
+ case 1:
+ pull = PIN_CONFIG_BIAS_PULL_DOWN;
+ break;
+ case 2:
+ pull = PIN_CONFIG_BIAS_PULL_UP;
+ break;
+ }
configs[0] = pull;
map->type = PIN_MAP_TYPE_CONFIGS_PIN;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Jan 23
Hi Paul, On Thu, 23 Jan 2014 17:21:09 +1100 Stephen Rothwell wrote: > > Changes since 20140122: > > The init tree lost one of its patches. It turns out that I merged yesterday's version of the init tree again today (so the fixes that went in do not appear). Sorry about that, I will try to do better tomorrow. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpusXTO0yRHC.pgp Description: PGP signature
RE: [PATCH 6/8] ASoC: simple-card: add tdm slot supports
Hi David,
Firstly thanks for your comment.
> > +asoc_simple_card_of_parse_tdm_slot(struct device_node *np,
> > + struct device *dev,
> > + struct asoc_simple_dai *dai,
> > + const char *propname)
> > +{
> > + struct asoc_simple_tdm_slot *tdm;
> > + u32 out_value[4];
> > + int ret;
> > +
> > + if (!of_property_read_bool(np, propname))
> > + return 0;
> > +
> > + tdm = devm_kzalloc(dev, sizeof(*tdm), GFP_KERNEL);
> > + if (!tdm)
> > + return -ENOMEM;
> > +
> > + ret = of_property_read_u32_array(np, propname, out_value, 4);
> > + if (ret)
> > + return ret;
>
> Looks like a memory leak?
>
Using devm_ and this will be called by _probe().
Please see the "Documentation/driver-model/devres.txt" for detail about
devres.
> > +
> > + tdm->tx_mask = out_value[0];
> > + tdm->rx_mask = out_value[1];
> > + tdm->slots = out_value[2];
> > + tdm->slot_width = out_value[3];
> > +
> > + dai->tdm = tdm;
> > +
> > + return 0;
> > +}
> > +
Thanks,
Best Regards,
Xiubo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm: vt8500: Fix gpio mux setup in vt8500_init()
With the switch to a pinctrl driver, and the dropping of the gpio driver,
the code in vt8500_init now always fails, and drops back to LEGACY mode.
Update the gpio mux init code, and removing the #ifdef's and the LEGACY
mode fallback.
Signed-off-by: Tony Prisk
---
arch/arm/mach-vt8500/vt8500.c | 91 ++---
1 file changed, 30 insertions(+), 61 deletions(-)
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index 4a73464..fe5243e 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -32,9 +32,6 @@
#include
#include
-#define LEGACY_GPIO_BASE 0xD811
-#define LEGACY_PMC_BASE0xD813
-
/* Registers in GPIO Controller */
#define VT8500_GPIO_MUX_REG0x200
@@ -75,89 +72,61 @@ static void vt8500_power_off(void)
void __init vt8500_init(void)
{
struct device_node *np;
-#if defined(CONFIG_FB_VT8500) || defined(CONFIG_FB_WM8505)
struct device_node *fb;
- void __iomem *gpio_base;
-#endif
+ void __iomem *base;
-#ifdef CONFIG_FB_VT8500
fb = of_find_compatible_node(NULL, NULL, "via,vt8500-fb");
if (fb) {
- np = of_find_compatible_node(NULL, NULL, "via,vt8500-gpio");
- if (np) {
- gpio_base = of_iomap(np, 0);
-
- if (!gpio_base)
- pr_err("%s: of_iomap(gpio_mux) failed\n",
- __func__);
+ np = of_find_compatible_node(NULL, NULL, "via,vt8500-pinctrl");
+ if (!np) {
+ pr_err("pinctrl node required for framebuffer\n");
+ BUG();
+ }
- of_node_put(np);
+ base = of_iomap(np, 0);
+ if (base) {
+ writel(readl(base + VT8500_GPIO_MUX_REG) | 1,
+ base + VT8500_GPIO_MUX_REG);
+ iounmap(base);
} else {
- gpio_base = ioremap(LEGACY_GPIO_BASE, 0x1000);
- if (!gpio_base)
- pr_err("%s: ioremap(legacy_gpio_mux) failed\n",
- __func__);
+ pr_err("%s: of_iomap(gpio_mux) failed\n", __func__);
}
- if (gpio_base) {
- writel(readl(gpio_base + VT8500_GPIO_MUX_REG) | 1,
- gpio_base + VT8500_GPIO_MUX_REG);
- iounmap(gpio_base);
- } else
- pr_err("%s: Could not remap GPIO mux\n", __func__);
+ of_node_put(np);
of_node_put(fb);
}
-#endif
-#ifdef CONFIG_FB_WM8505
fb = of_find_compatible_node(NULL, NULL, "wm,wm8505-fb");
if (fb) {
- np = of_find_compatible_node(NULL, NULL, "wm,wm8505-gpio");
- if (!np)
- np = of_find_compatible_node(NULL, NULL,
- "wm,wm8650-gpio");
- if (np) {
- gpio_base = of_iomap(np, 0);
-
- if (!gpio_base)
- pr_err("%s: of_iomap(gpio_mux) failed\n",
- __func__);
-
- of_node_put(np);
+ np = of_find_compatible_node(NULL, NULL, "wm,prizm-pinctrl");
+ if (!np) {
+ pr_err("pinctrl node required for framebuffer\n");
+ BUG();
+ }
+
+ base = of_iomap(np, 0);
+ if (base) {
+ writel(readl(base + VT8500_GPIO_MUX_REG) |
+ 0x8000, base + VT8500_GPIO_MUX_REG);
+ iounmap(base);
} else {
- gpio_base = ioremap(LEGACY_GPIO_BASE, 0x1000);
- if (!gpio_base)
- pr_err("%s: ioremap(legacy_gpio_mux) failed\n",
- __func__);
+ pr_err("%s: of_iomap(gpio_mux) failed\n", __func__);
}
- if (gpio_base) {
- writel(readl(gpio_base + VT8500_GPIO_MUX_REG) |
- 0x8000, gpio_base + VT8500_GPIO_MUX_REG);
- iounmap(gpio_base);
- } else
- pr_err("%s: Could not remap GPIO mux\n", __func__);
+ of_node_put(np);
of_node_put(fb);
}
-#endif
np = of_find_compatible_node(NULL, NULL, "via,vt8500-pmc");
if (np) {
pmc_base = of_iomap(np, 0);
-
- if (!pmc_base)
- pr_err("%s:of_iomap(pmc) failed\n", __f
Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On 01/23/2014 02:13 PM, Dave Jones wrote: On Wed, Jan 22, 2014 at 10:06:14PM -0800, David Rientjes wrote: > On Thu, 23 Jan 2014, Tang Chen wrote: > .. > > I guess it depends on what Dave's CONFIG_NODES_SHIFT is? It's 10, because I had MAXSMP set. So, MAX_NUMNODES = 1<< 10 And the bitmask is made of longs. 1024 of them. How does this work ? I have the same config with you. Would you please try it for me ? Does it work on your box ? I cannot reproduce this problem on the latest kernel. But I can reproduce it on 3.10. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zswap: Check all pool pages instead of one pool pages
Hello Minchan
2014/1/23 Minchan Kim :
> Hello Cai,
>
> On Thu, Jan 23, 2014 at 09:38:41AM +0800, Cai Liu wrote:
>> Hello Dan
>>
>> 2014/1/22 Dan Streetman :
>> > On Wed, Jan 22, 2014 at 7:16 AM, Cai Liu wrote:
>> >> Hello Minchan
>> >>
>> >>
>> >> 2014/1/22 Minchan Kim
>> >>>
>> >>> Hello Cai,
>> >>>
>> >>> On Tue, Jan 21, 2014 at 09:52:25PM +0800, Cai Liu wrote:
>> >>> > Hello Minchan
>> >>> >
>> >>> > 2014/1/21 Minchan Kim :
>> >>> > > Hello,
>> >>> > >
>> >>> > > On Tue, Jan 21, 2014 at 02:35:07PM +0800, Cai Liu wrote:
>> >>> > >> 2014/1/21 Minchan Kim :
>> >>> > >> > Please check your MUA and don't break thread.
>> >>> > >> >
>> >>> > >> > On Tue, Jan 21, 2014 at 11:07:42AM +0800, Cai Liu wrote:
>> >>> > >> >> Thanks for your review.
>> >>> > >> >>
>> >>> > >> >> 2014/1/21 Minchan Kim :
>> >>> > >> >> > Hello Cai,
>> >>> > >> >> >
>> >>> > >> >> > On Mon, Jan 20, 2014 at 03:50:18PM +0800, Cai Liu wrote:
>> >>> > >> >> >> zswap can support multiple swapfiles. So we need to check
>> >>> > >> >> >> all zbud pool pages in zswap.
>> >>> > >> >> >>
>> >>> > >> >> >> Version 2:
>> >>> > >> >> >> * add *total_zbud_pages* in zbud to record all the pages in
>> >>> > >> >> >> pools
>> >>> > >> >> >> * move the updating of pool pages statistics to
>> >>> > >> >> >> alloc_zbud_page/free_zbud_page to hide the details
>> >>> > >> >> >>
>> >>> > >> >> >> Signed-off-by: Cai Liu
>> >>> > >> >> >> ---
>> >>> > >> >> >> include/linux/zbud.h |2 +-
>> >>> > >> >> >> mm/zbud.c| 44
>> >>> > >> >> >>
>> >>> > >> >> >> mm/zswap.c |4 ++--
>> >>> > >> >> >> 3 files changed, 35 insertions(+), 15 deletions(-)
>> >>> > >> >> >>
>> >>> > >> >> >> diff --git a/include/linux/zbud.h b/include/linux/zbud.h
>> >>> > >> >> >> index 2571a5c..1dbc13e 100644
>> >>> > >> >> >> --- a/include/linux/zbud.h
>> >>> > >> >> >> +++ b/include/linux/zbud.h
>> >>> > >> >> >> @@ -17,6 +17,6 @@ void zbud_free(struct zbud_pool *pool,
>> >>> > >> >> >> unsigned long handle);
>> >>> > >> >> >> int zbud_reclaim_page(struct zbud_pool *pool, unsigned int
>> >>> > >> >> >> retries);
>> >>> > >> >> >> void *zbud_map(struct zbud_pool *pool, unsigned long handle);
>> >>> > >> >> >> void zbud_unmap(struct zbud_pool *pool, unsigned long
>> >>> > >> >> >> handle);
>> >>> > >> >> >> -u64 zbud_get_pool_size(struct zbud_pool *pool);
>> >>> > >> >> >> +u64 zbud_get_pool_size(void);
>> >>> > >> >> >>
>> >>> > >> >> >> #endif /* _ZBUD_H_ */
>> >>> > >> >> >> diff --git a/mm/zbud.c b/mm/zbud.c
>> >>> > >> >> >> index 9451361..711aaf4 100644
>> >>> > >> >> >> --- a/mm/zbud.c
>> >>> > >> >> >> +++ b/mm/zbud.c
>> >>> > >> >> >> @@ -52,6 +52,13 @@
>> >>> > >> >> >> #include
>> >>> > >> >> >> #include
>> >>> > >> >> >>
>> >>> > >> >> >> +/*
>> >>> > >> >> >> +* statistics
>> >>> > >> >> >> +**/
>> >>> > >> >> >> +
>> >>> > >> >> >> +/* zbud pages in all pools */
>> >>> > >> >> >> +static u64 total_zbud_pages;
>> >>> > >> >> >> +
>> >>> > >> >> >> /*
>> >>> > >> >> >> * Structures
>> >>> > >> >> >> */
>> >>> > >> >> >> @@ -142,10 +149,28 @@ static struct zbud_header
>> >>> > >> >> >> *init_zbud_page(struct page *page)
>> >>> > >> >> >> return zhdr;
>> >>> > >> >> >> }
>> >>> > >> >> >>
>> >>> > >> >> >> +static struct page *alloc_zbud_page(struct zbud_pool *pool,
>> >>> > >> >> >> gfp_t gfp)
>> >>> > >> >> >> +{
>> >>> > >> >> >> + struct page *page;
>> >>> > >> >> >> +
>> >>> > >> >> >> + page = alloc_page(gfp);
>> >>> > >> >> >> +
>> >>> > >> >> >> + if (page) {
>> >>> > >> >> >> + pool->pages_nr++;
>> >>> > >> >> >> + total_zbud_pages++;
>> >>> > >> >> >
>> >>> > >> >> > Who protect race?
>> >>> > >> >>
>> >>> > >> >> Yes, here the pool->pages_nr and also the total_zbud_pages are
>> >>> > >> >> not protected.
>> >>> > >> >> I will re-do it.
>> >>> > >> >>
>> >>> > >> >> I will change *total_zbud_pages* to atomic type.
>> >>> > >> >
>> >>> > >> > Wait, it doesn't make sense. Now, you assume zbud allocator would
>> >>> > >> > be used
>> >>> > >> > for only zswap. It's true until now but we couldn't make sure it
>> >>> > >> > in future.
>> >>> > >> > If other user start to use zbud allocator, total_zbud_pages would
>> >>> > >> > be pointless.
>> >>> > >>
>> >>> > >> Yes, you are right. ZBUD is a common module. So in this patch
>> >>> > >> calculate the
>> >>> > >> zswap pool size in zbud is not suitable.
>> >>> > >>
>> >>> > >> >
>> >>> > >> > Another concern is that what's your scenario for above two swap?
>> >>> > >> > How often we need to call zbud_get_pool_size?
>> >>> > >> > In previous your patch, you reduced the number of call so IIRC,
>> >>> > >> > we only called it in zswap_is_full and for debugfs.
>> >>> > >>
>> >>> > >> zbud_get_pool_size() is called frequently when adding/freeing zswap
>> >>> > >> entry happen in zsw
Re: [Bug 67651] Bisected: Lots of fragmented mmaps cause gimp to fail in 3.12 after exceeding vm_max_map_count
On Wed, Jan 22, 2014 at 10:09:10PM -0800, Andrew Morton wrote: > > > > > > That being said, this could cause vma blowups for programs that are > > > actually using this thing. > > > > Hi Andy, indeed, this could happen. The easiest way is to ignore softdirty > > bit > > when we're trying to merge vmas and set it one new merged. I think this > > should > > be correct. Once I finish I'll send the patch. > > Hang on. We think the problem is that gimp is generating vmas which > *should* be merged, but for unknown reasons they differ in > VM_SOFTDIRTY, yes? Yes. One place where I forgot to set softdirty bit is setup_arg_pages. But it called once on elf load, so it can't cause such effect (but should be fixed too). Also there is do_brk where vmasoftdirty is missed too :/ Another problem is the potential scenario when we have a bunch of vmas and clear vma-softdirty bit on them, then we try to map new one, flags won't match and instead of extending old vma the new one will be created. I think (if only I'm not missing something) that vma-softdirty should be ignored in such case (ie inside is_mergeable_vma) and once vma extended it should be marked as dirty one. Again, I need to think and test more. > Shouldn't we work out where we're forgetting to set VM_SOFTDIRTY? > Putting bandaids over this error when we come to trying to merge the > vmas sounds very wrong? I'm looking into this as well. Cyrill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jan 23
Hi all, This tree fails (more than usual) the powerpc allyesconfig build. Changes since 20140122: Removed trees: sh, sh-current Dropped tree: imx-mxs (complex merge conflicts against the arm tree) The powerpc tree still had its build failure. The arm-soc tree gained a conflict against Linus' tree. The userns tree gained a conflict against the mips tree. The init tree lost one of its patches. Non-merge commits (relative to Linus' tree): 6876 7279 files changed, 331484 insertions(+), 151447 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. I am currently merging 208 trees (counting Linus' and 28 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (df32e43a54d0 Merge branch 'akpm' (incoming from Andrew)) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (19514fc665ff arm, kbuild: make "make install" not depend on vmlinux) Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8) Merging arm-current/fixes (b25f3e1c3584 ARM: 7938/1: OMAP4/highbank: Flush L2 cache before disabling) Merging m68k-current/for-linus (56931d73697c m68k/mac: Make SCC reset work more reliably) Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2) Merging powerpc-merge/merge (b3084f4db3ae powerpc/thp: Fix crash on mremap) Merging sparc/master (ef350bb7c5e0 Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) Merging net/master (7d0d46da750a Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging ipsec/master (965cdea82569 dccp: catch failed request_module call in dccp_probe init) Merging sound-current/for-linus (2387083157b8 ALSA: hda - Apply +5dB output amp on ASUS Zenbook UX31A) Merging pci-current/for-linus (f0b75693cbb2 MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers) Merging wireless/master (2eff7c791a18 Merge tag 'nfc-fixes-3.13-1' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes) Merging driver-core.current/driver-core-linus (413541dd66d5 Linux 3.13-rc5) Merging tty.current/tty-linus (413541dd66d5 Linux 3.13-rc5) Merging usb.current/usb-linus (413541dd66d5 Linux 3.13-rc5) Merging staging.current/staging-linus (413541dd66d5 Linux 3.13-rc5) Merging char-misc.current/char-misc-linus (802eee95bde7 Linux 3.13-rc6) Merging input-current/for-linus (8e2f2325b73f Input: xpad - add new USB IDs for Logitech F310 and F710) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (efb753b8e013 crypto: ixp4xx - Fix kernel compile error) Merging ide/master (c2f7d1e103ef ide: pmac: remove unnecessary pci_set_drvdata()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (6f041e99fc7b of: Fix NULL dereference in unflatten_and_copy()) Merging rr-fixes/fixes (7122c3e9154b scripts/link-vmlinux.sh: only filter kernel symbols for arm) Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interru
Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On Thu, 23 Jan 2014, Dave Jones wrote: > It's 10, because I had MAXSMP set. > > So, MAX_NUMNODES = 1 << 10 > > And the bitmask is made of longs. 1024 of them. > > How does this work ? > It's 1024 bits. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On Wed, Jan 22, 2014 at 10:06:14PM -0800, David Rientjes wrote: > On Thu, 23 Jan 2014, Tang Chen wrote: > > > Dave found that the kernel will hang during boot. This is because > > the nodemask_t type stack variable numa_kernel_nodes is large enough > > to overflow the stack. > > > > This doesn't always happen. According to Dave, this happened once > > in about five boots. The backtrace is like the following: > > > > dump_stack > > panic > > ? numa_clear_kernel_node_hotplug > > __stack_chk_fail > > numa_clear_kernel_node_hotplug > > ? memblock_search_pfn_nid > > ? __early_pfn_to_nid > > numa_init > > x86_numa_init > > initmem_init > > setup_arch > > start_kernel > > > > This patch fix this problem by defining numa_kernel_nodes as a > > static global variable in __initdata area. > > > > Reported-by: Dave Jones > > Signed-off-by: Tang Chen > > Tested-by: Gu Zheng > > I guess it depends on what Dave's CONFIG_NODES_SHIFT is? It's 10, because I had MAXSMP set. So, MAX_NUMNODES = 1 << 10 And the bitmask is made of longs. 1024 of them. How does this work ? Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] ASoC: simple-card: add tdm slot supports
On Thu, 23 Jan 2014, Xiubo Li wrote:
> diff --git a/include/sound/simple_card.h b/include/sound/simple_card.h
> index e1ac996..cfc5b66 100644
> --- a/include/sound/simple_card.h
> +++ b/include/sound/simple_card.h
> @@ -14,10 +14,18 @@
>
> #include
>
> +struct asoc_simple_tdm_slot {
> + unsigned int tx_mask;
> + unsigned int rx_mask;
> + int slots;
> + int slot_width;
> +};
> +
> struct asoc_simple_dai {
> const char *name;
> unsigned int fmt;
> unsigned int sysclk;
> + struct asoc_simple_tdm_slot *tdm;
> };
>
> struct asoc_simple_card_info {
> diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
> index 546b93d..d067e0a 100644
> --- a/sound/soc/generic/simple-card.c
> +++ b/sound/soc/generic/simple-card.c
> @@ -32,7 +32,7 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai
> *dai,
> ret = snd_soc_dai_set_fmt(dai, set->fmt);
> if (ret && ret != -ENOTSUPP) {
> dev_err(dai->dev, "simple-card: set_fmt error\n");
> - return ret;
> + goto err;
> }
> }
>
> @@ -40,10 +40,22 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai
> *dai,
> ret = snd_soc_dai_set_sysclk(dai, 0, set->sysclk, 0);
> if (ret && ret != -ENOTSUPP) {
> dev_err(dai->dev, "simple-card: set_sysclk error\n");
> - return ret;
> + goto err;
> + }
> + }
> +
> + if (set->tdm) {
> + ret = snd_soc_dai_set_tdm_slot(dai, set->tdm->tx_mask,
> + set->tdm->rx_mask,
> + set->tdm->slots,
> + set->tdm->slot_width);
> + if (ret && ret != -ENOTSUPP) {
> + dev_err(dai->dev, "simple-card: set_tdm_slot error\n");
> + goto err;
> }
> }
>
> +err:
> return ret;
> }
>
> @@ -67,11 +79,43 @@ static int asoc_simple_card_dai_init(struct
> snd_soc_pcm_runtime *rtd)
> }
>
> static int
> +asoc_simple_card_of_parse_tdm_slot(struct device_node *np,
> +struct device *dev,
> +struct asoc_simple_dai *dai,
> +const char *propname)
> +{
> + struct asoc_simple_tdm_slot *tdm;
> + u32 out_value[4];
> + int ret;
> +
> + if (!of_property_read_bool(np, propname))
> + return 0;
> +
> + tdm = devm_kzalloc(dev, sizeof(*tdm), GFP_KERNEL);
> + if (!tdm)
> + return -ENOMEM;
> +
> + ret = of_property_read_u32_array(np, propname, out_value, 4);
> + if (ret)
> + return ret;
Looks like a memory leak?
> +
> + tdm->tx_mask = out_value[0];
> + tdm->rx_mask = out_value[1];
> + tdm->slots = out_value[2];
> + tdm->slot_width = out_value[3];
> +
> + dai->tdm = tdm;
> +
> + return 0;
> +}
> +
> +static int
> asoc_simple_card_sub_parse_of(struct device_node *np,
> unsigned int daifmt,
> struct asoc_simple_dai *dai,
> const struct device_node **p_node,
> - const char **name)
> + const char **name,
> + struct device *dev)
> {
> struct device_node *node;
> struct clk *clk;
> @@ -91,6 +135,11 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
> if (ret < 0)
> goto parse_error;
>
> + /* parse tdm_slot */
> + ret = asoc_simple_card_of_parse_tdm_slot(np, dev, dai, "tdm-slot");
> + if (ret < 0)
> + goto parse_error;
> +
> /*
>* bitclock-inversion, frame-inversion
>* bitclock-master,frame-master
> @@ -162,7 +211,8 @@ static int asoc_simple_card_parse_of(struct device_node
> *node,
> ret = asoc_simple_card_sub_parse_of(np, priv->daifmt,
> &priv->cpu_dai,
> &dai_link->cpu_of_node,
> - &dai_link->cpu_dai_name);
> + &dai_link->cpu_dai_name,
> + dev);
> if (ret < 0)
> return ret;
>
> @@ -173,7 +223,8 @@ static int asoc_simple_card_parse_of(struct device_node
> *node,
> ret = asoc_simple_card_sub_parse_of(np, priv->daifmt,
> &priv->codec_dai,
> &dai_link->codec_of_node,
> - &dai_link->codec_dai_name);
> + &dai_link->codec_dai_name,
> + de
[PATCH 5/8] ASoC: core: set_tdm_slot() will return -ENOTSUPP if no operation provided
Make it easier for generic code to work with set_tdm_slot() by distinguishing between the operation not being supported and an error as is done. Signed-off-by: Xiubo Li --- sound/soc/soc-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index fe1df50..393ff06 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -3626,7 +3626,7 @@ int snd_soc_dai_set_tdm_slot(struct snd_soc_dai *dai, return dai->driver->ops->set_tdm_slot(dai, tx_mask, rx_mask, slots, slot_width); else - return -EINVAL; + return -ENOTSUPP; } EXPORT_SYMBOL_GPL(snd_soc_dai_set_tdm_slot); -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Arndale Timer Interrupt Question
On 1/10/14, Tomasz Figa wrote: > Hi, > > On 09.01.2014 13:52, Bartlomiej Zolnierkiewicz wrote: >> >> added linux-samsung-soc to cc:, >> it is a better suited list for this question >> >> On Thursday, January 09, 2014 10:30:56 AM Mj Embd wrote: >>> I am a bit confused on the interrupt number for CNTVIRQ..CNTHPIRQ. Can >>> you please help here. >>> >>> As per the exynos5 public manual >>> What is the difference between CPU_nCNTHPIRQ[0] and CNTHPIRQ. > > I'm not sure if this is really what I think it is, but looking at the > manual, CPU_nCNTHPIRQ[0] and [1] SPI ports and CNTHPIRQ PPI port seem to > be the same signals, with the difference that the first two are shared > interrupts connected through the combiner, while the last one is a > per-processor interrupt, directly connected to GIC PPI port, allowing > each CPU to get its own CNTHPIRQ signal ([0] for CPU 0 and [1] for CPU 1). So while registering the IRQ which one has to be used Core0:26/33 Core1:26/54 ? > Best regards, > Tomasz > >>> >>> While the later has an interrupt ID 26, the former is part of a group >>> with combined interrupt id as 33 for core 0 and 54 for core 1. >>> >>> For a timer interrupt which goes to PL2, which id should be used 26 or >>> 33 for core 0 ? >>> >>> Please clear this confusion. >>> >>> Many Thanks >> >> -- >> To unsubscribe from this list: send the line "unsubscribe >> linux-samsung-soc" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- -mj -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] (xen) stable/for-linus-3.14-rc0-tag
On Wed, Jan 22, 2014 at 11:36 AM, Konrad Rzeszutek Wilk
wrote:
>
> 46 files changed, 3379 insertions(+), 2117 deletions(-)
Please fix your script to detect renames - add '-M' to your "git diff
--stat" line (and '--summary' too, for that matter)
The correct statistics are actually
45 files changed, 1952 insertions(+), 690 deletions(-)
rename drivers/xen/{events.c => events/events_base.c} (70%)
as rename detection would have shown.
(Rename detection isn't the default for git, because the resulting
diffs aren't applicable by old broken versions of patch. Some day I
might ask Junio to consider making it the default, but in the name of
interoperability that day is years from now.. GNU patch actually does
understand rename diffs, but other tools like diffstat etc still
don't)
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On Thu, 23 Jan 2014, Tang Chen wrote:
> Dave found that the kernel will hang during boot. This is because
> the nodemask_t type stack variable numa_kernel_nodes is large enough
> to overflow the stack.
>
> This doesn't always happen. According to Dave, this happened once
> in about five boots. The backtrace is like the following:
>
> dump_stack
> panic
> ? numa_clear_kernel_node_hotplug
> __stack_chk_fail
> numa_clear_kernel_node_hotplug
> ? memblock_search_pfn_nid
> ? __early_pfn_to_nid
> numa_init
> x86_numa_init
> initmem_init
> setup_arch
> start_kernel
>
> This patch fix this problem by defining numa_kernel_nodes as a
> static global variable in __initdata area.
>
> Reported-by: Dave Jones
> Signed-off-by: Tang Chen
> Tested-by: Gu Zheng
I guess it depends on what Dave's CONFIG_NODES_SHIFT is?
> ---
> arch/x86/mm/numa.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index 81b2750..ebefeb7 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -562,10 +562,10 @@ static void __init numa_init_array(void)
> }
> }
>
> +static nodemask_t numa_kernel_nodes __initdata;
> static void __init numa_clear_kernel_node_hotplug(void)
> {
> int i, nid;
> - nodemask_t numa_kernel_nodes;
> unsigned long start, end;
> struct memblock_type *type = &memblock.reserved;
>
Isn't this also a bugfix since you never initialize numa_kernel_nodes when
it's allocated on the stack with NODE_MASK_NONE?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 67651] Bisected: Lots of fragmented mmaps cause gimp to fail in 3.12 after exceeding vm_max_map_count
On Thu, 23 Jan 2014 09:59:06 +0400 Cyrill Gorcunov wrote: > On Wed, Jan 22, 2014 at 02:45:53PM -0800, Andy Lutomirski wrote: > > > > > > Thus when user space application track memory changes now it can > > > detect if > > > vma area is renewed. > > > > Presumably some path is failing to set VM_SOFTDIRTY, thus preventing mms > > from being merged. > > > > That being said, this could cause vma blowups for programs that are > > actually using this thing. > > Hi Andy, indeed, this could happen. The easiest way is to ignore softdirty bit > when we're trying to merge vmas and set it one new merged. I think this should > be correct. Once I finish I'll send the patch. Hang on. We think the problem is that gimp is generating vmas which *should* be merged, but for unknown reasons they differ in VM_SOFTDIRTY, yes? Shouldn't we work out where we're forgetting to set VM_SOFTDIRTY? Putting bandaids over this error when we come to trying to merge the vmas sounds very wrong? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/8] New and Resend the old patches
New and Resend the old patches basing the newest code version. And this patch series has been tested based the VF610 Tower board. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH Resend 2/8] ASoC: simple-card: fix __asoc_simple_card_dai_init
If the CPU/CODEC DAI set_sysclk() is not support, the -ENOTSUPP will returnd.
Here do the check like set_fmt().
Signed-off-by: Xiubo Li
---
The VF610 Tower and VF610 LS1 platforms' ESAI and SPDIF will depend on this
patch too.
sound/soc/generic/simple-card.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 6443c87..3b8c9a2 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -31,16 +31,21 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai
*dai,
daifmt |= set->fmt;
- if (daifmt)
+ if (daifmt) {
ret = snd_soc_dai_set_fmt(dai, daifmt);
-
- if (ret == -ENOTSUPP) {
- dev_dbg(dai->dev, "ASoC: set_fmt is not supported\n");
- ret = 0;
+ if (ret && ret != -ENOTSUPP) {
+ dev_err(dai->dev, "simple-card: set_fmt error\n");
+ return ret;
+ }
}
- if (!ret && set->sysclk)
+ if (set->sysclk) {
ret = snd_soc_dai_set_sysclk(dai, 0, set->sysclk, 0);
+ if (ret && ret != -ENOTSUPP) {
+ dev_err(dai->dev, "simple-card: set_sysclk error\n");
+ return ret;
+ }
+ }
return ret;
}
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH Resend 3/8] ASoC: simple-card: simplify the daifmt code
In the asoc_simple_card_parse_of() will parse the device node's CPU/CODEC
DAI commone fmts, and then in asoc_simple_card_sub_parse_of() will parse
the CPU/CODEC DAI's sub-node fmts, so we can combine the info->daifmt and
info->set.fmt in asoc_simple_card_sub_parse_of() not while just before
_set_fmt().
And this will be more easy to add new functions, such as supporting
_set_tdm_slot(), etc.
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 3b8c9a2..f38e56e 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -24,15 +24,12 @@ struct simple_card_data {
};
static int __asoc_simple_card_dai_init(struct snd_soc_dai *dai,
- struct asoc_simple_dai *set,
- unsigned int daifmt)
+ struct asoc_simple_dai *set)
{
int ret = 0;
- daifmt |= set->fmt;
-
- if (daifmt) {
- ret = snd_soc_dai_set_fmt(dai, daifmt);
+ if (set->fmt) {
+ ret = snd_soc_dai_set_fmt(dai, set->fmt);
if (ret && ret != -ENOTSUPP) {
dev_err(dai->dev, "simple-card: set_fmt error\n");
return ret;
@@ -56,14 +53,13 @@ static int asoc_simple_card_dai_init(struct
snd_soc_pcm_runtime *rtd)
snd_soc_card_get_drvdata(rtd->card);
struct snd_soc_dai *codec = rtd->codec_dai;
struct snd_soc_dai *cpu = rtd->cpu_dai;
- unsigned int daifmt = priv->daifmt;
int ret;
- ret = __asoc_simple_card_dai_init(codec, &priv->codec_dai, daifmt);
+ ret = __asoc_simple_card_dai_init(codec, &priv->codec_dai);
if (ret < 0)
return ret;
- ret = __asoc_simple_card_dai_init(cpu, &priv->cpu_dai, daifmt);
+ ret = __asoc_simple_card_dai_init(cpu, &priv->cpu_dai);
if (ret < 0)
return ret;
@@ -72,6 +68,7 @@ static int asoc_simple_card_dai_init(struct
snd_soc_pcm_runtime *rtd)
static int
asoc_simple_card_sub_parse_of(struct device_node *np,
+ unsigned int daifmt,
struct asoc_simple_dai *dai,
const struct device_node **p_node,
const char **name)
@@ -100,6 +97,7 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
* and specific "format" if it has
*/
dai->fmt = snd_soc_of_parse_daifmt(np, NULL);
+ dai->fmt |= daifmt;
/*
* dai->sysclk come from
@@ -158,7 +156,7 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
ret = -EINVAL;
np = of_get_child_by_name(node, "simple-audio-card,cpu");
if (np)
- ret = asoc_simple_card_sub_parse_of(np,
+ ret = asoc_simple_card_sub_parse_of(np, priv->daifmt,
&priv->cpu_dai,
&dai_link->cpu_of_node,
&dai_link->cpu_dai_name);
@@ -169,7 +167,7 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
ret = -EINVAL;
np = of_get_child_by_name(node, "simple-audio-card,codec");
if (np)
- ret = asoc_simple_card_sub_parse_of(np,
+ ret = asoc_simple_card_sub_parse_of(np, priv->daifmt,
&priv->codec_dai,
&dai_link->codec_of_node,
&dai_link->codec_dai_name);
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] ASoC: fsl: Add VF610 soc audio card Kconfig
Signed-off-by: Xiubo Li --- sound/soc/fsl/Kconfig | 24 1 file changed, 24 insertions(+) diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index 324988d..bc1fa9c 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -219,3 +219,27 @@ config SND_SOC_IMX_MC13783 select SND_SOC_IMX_PCM_DMA endif # SND_IMX_SOC + +menuconfig SND_VF610_SOC + tristate "SoC Audio for Freescale VF610 CPUs" + select DMA_ENGINE + help + Say Y or M if you want to add support for codecs attached to + the VF610 CPUs. + + This will enable Freeacale SAI and SGTL5000 codec, and an extra + TWR-AUDIO-SGTL sub-board is needed for SGTL5000. + +if SND_VF610_SOC + +config SND_SOC_VF610_SGTL5000 + tristate "SoC Audio support for VF610 boards with SGTL5000" + depends on OF && I2C + select SND_SOC_FSL_SAI + select SND_SOC_SGTL5000 + select SND_SIMPLE_CARD + help + Say Y if you want to add support for SoC audio on an VF610 board with + a SGTL5000 codec and a SAI. + +endif #SND_VF610_SOC -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On Thu, 23 Jan 2014 13:49:28 +0800 Tang Chen wrote:
> Dave found that the kernel will hang during boot. This is because
> the nodemask_t type stack variable numa_kernel_nodes is large enough
> to overflow the stack.
>
> This doesn't always happen. According to Dave, this happened once
> in about five boots. The backtrace is like the following:
>
> dump_stack
> panic
> ? numa_clear_kernel_node_hotplug
> __stack_chk_fail
> numa_clear_kernel_node_hotplug
> ? memblock_search_pfn_nid
> ? __early_pfn_to_nid
> numa_init
> x86_numa_init
> initmem_init
> setup_arch
> start_kernel
>
> This patch fix this problem by defining numa_kernel_nodes as a
> static global variable in __initdata area.
>
> ...
>
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -562,10 +562,10 @@ static void __init numa_init_array(void)
> }
> }
>
> +static nodemask_t numa_kernel_nodes __initdata;
> static void __init numa_clear_kernel_node_hotplug(void)
> {
> int i, nid;
> - nodemask_t numa_kernel_nodes;
> unsigned long start, end;
> struct memblock_type *type = &memblock.reserved;
Seems odd. The maximum size of a nodemask_t is 128 bytes, isn't it?
If so, what the heck have we done in there to consume so much stack?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH Resend 7/8] ASoC: add snd_soc_of_parse_audio_simple_widgets for DeviceTree
This patch adds snd_soc_of_parse_audio_simple_widgets() and supports
below style of widgets name on DT.
"wname-prefix[ individual name]"
"wname-prefix" includes: "Mic", "Line", "Hp", "Spk"...
For instance:
simple-audio-widgets =
"Mic Jack", "Line In Jack",
"Hp Jack", "Spk Ext",
"Line Out Jack";
Signed-off-by: Xiubo Li
---
Add :
widgets[i].name = wname;
And this will use the widget name from DT node.
include/sound/soc.h | 2 ++
sound/soc/soc-core.c | 63
2 files changed, 65 insertions(+)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 9a00147..465dc6e 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1173,6 +1173,8 @@ void snd_soc_util_exit(void);
int snd_soc_of_parse_card_name(struct snd_soc_card *card,
const char *propname);
+int snd_soc_of_parse_audio_simple_widgets(struct snd_soc_card *card,
+ const char *propname);
int snd_soc_of_parse_audio_routing(struct snd_soc_card *card,
const char *propname);
unsigned int snd_soc_of_parse_daifmt(struct device_node *np,
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 393ff06..9c8a686 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -4417,6 +4417,69 @@ int snd_soc_of_parse_card_name(struct snd_soc_card *card,
}
EXPORT_SYMBOL_GPL(snd_soc_of_parse_card_name);
+static struct snd_soc_dapm_widget simple_widgets[] = {
+ SND_SOC_DAPM_MIC("Mic", NULL),
+ SND_SOC_DAPM_LINE("Line", NULL),
+ SND_SOC_DAPM_HP("Hp", NULL),
+ SND_SOC_DAPM_SPK("Spk", NULL),
+};
+
+int snd_soc_of_parse_audio_simple_widgets(struct snd_soc_card *card,
+ const char *propname)
+{
+ struct device_node *np = card->dev->of_node;
+ struct snd_soc_dapm_widget *widgets;
+ const char *wname;
+ int i, j, cnt, ret;
+
+ cnt = of_property_count_strings(np, propname);
+ if (cnt <= 0) {
+ dev_err(card->dev,
+ "ASoC: Property '%s' does not exist or "
+ "length is zero\n", propname);
+ return -EINVAL;
+ }
+
+ widgets = devm_kcalloc(card->dev, cnt, sizeof(*widgets), GFP_KERNEL);
+ if (!widgets) {
+ dev_err(card->dev,
+ "ASoC: Could not allocate DAPM widgets table\n");
+ return -ENOMEM;
+ }
+
+ for (i = 0; i < cnt; i++) {
+ ret = of_property_read_string_index(np, propname, i, &wname);
+ if (ret) {
+ dev_err(card->dev,
+ "ASoC: Property '%s' index %d could not be "
+ "read: %d\n", propname, i, ret);
+ return -EINVAL;
+ }
+
+ for (j = 0; j < ARRAY_SIZE(simple_widgets); j++) {
+ if (!strncmp(wname, simple_widgets[j].name,
+strlen(simple_widgets[j].name))) {
+ widgets[i] = simple_widgets[j];
+ widgets[i].name = wname;
+ break;
+ }
+ }
+
+ if (j >= ARRAY_SIZE(simple_widgets)) {
+ dev_err(card->dev,
+ "ASoC: DAPM widget : '%s' is not supported\n",
+ wname);
+ return -EINVAL;
+ }
+ }
+
+ card->dapm_widgets = widgets;
+ card->num_dapm_widgets = cnt;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_simple_widgets);
+
int snd_soc_of_parse_audio_routing(struct snd_soc_card *card,
const char *propname)
{
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] ASoC: simple-card: add off-codec widgets supports.
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 8
1 file changed, 8 insertions(+)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index d067e0a..4b7ef4d 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -196,6 +196,14 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
priv->daifmt = snd_soc_of_parse_daifmt(node, "simple-audio-card,") &
(SND_SOC_DAIFMT_FORMAT_MASK | SND_SOC_DAIFMT_INV_MASK);
+ /* off-codec widgets */
+ if (of_property_read_bool(node, "simple-audio-card,widgets")) {
+ ret = snd_soc_of_parse_audio_simple_widgets(&priv->snd_card,
+ "simple-audio-card,widgets");
+ if (ret)
+ return ret;
+ }
+
/* DAPM routes */
if (of_property_read_bool(node, "simple-audio-card,routing")) {
ret = snd_soc_of_parse_audio_routing(&priv->snd_card,
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/8] ASoC: simple-card: add tdm slot supports
For some CPU/CODEC DAI devices the tdm slot maybe needed. This patch
adds the tdm slot supporting for simple-card driver.
The style of the tdm slot in DT:
For instance:
simple-tdm-slot = <0xffc 0xffc 2 0>;
Signed-off-by: Xiubo Li
---
The VF610 Tower and VF610 LS1 platforms' SPDIF will depend on this patch.
include/sound/simple_card.h | 8 ++
sound/soc/generic/simple-card.c | 61 +
2 files changed, 64 insertions(+), 5 deletions(-)
diff --git a/include/sound/simple_card.h b/include/sound/simple_card.h
index e1ac996..cfc5b66 100644
--- a/include/sound/simple_card.h
+++ b/include/sound/simple_card.h
@@ -14,10 +14,18 @@
#include
+struct asoc_simple_tdm_slot {
+ unsigned int tx_mask;
+ unsigned int rx_mask;
+ int slots;
+ int slot_width;
+};
+
struct asoc_simple_dai {
const char *name;
unsigned int fmt;
unsigned int sysclk;
+ struct asoc_simple_tdm_slot *tdm;
};
struct asoc_simple_card_info {
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 546b93d..d067e0a 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -32,7 +32,7 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai
*dai,
ret = snd_soc_dai_set_fmt(dai, set->fmt);
if (ret && ret != -ENOTSUPP) {
dev_err(dai->dev, "simple-card: set_fmt error\n");
- return ret;
+ goto err;
}
}
@@ -40,10 +40,22 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai
*dai,
ret = snd_soc_dai_set_sysclk(dai, 0, set->sysclk, 0);
if (ret && ret != -ENOTSUPP) {
dev_err(dai->dev, "simple-card: set_sysclk error\n");
- return ret;
+ goto err;
+ }
+ }
+
+ if (set->tdm) {
+ ret = snd_soc_dai_set_tdm_slot(dai, set->tdm->tx_mask,
+ set->tdm->rx_mask,
+ set->tdm->slots,
+ set->tdm->slot_width);
+ if (ret && ret != -ENOTSUPP) {
+ dev_err(dai->dev, "simple-card: set_tdm_slot error\n");
+ goto err;
}
}
+err:
return ret;
}
@@ -67,11 +79,43 @@ static int asoc_simple_card_dai_init(struct
snd_soc_pcm_runtime *rtd)
}
static int
+asoc_simple_card_of_parse_tdm_slot(struct device_node *np,
+ struct device *dev,
+ struct asoc_simple_dai *dai,
+ const char *propname)
+{
+ struct asoc_simple_tdm_slot *tdm;
+ u32 out_value[4];
+ int ret;
+
+ if (!of_property_read_bool(np, propname))
+ return 0;
+
+ tdm = devm_kzalloc(dev, sizeof(*tdm), GFP_KERNEL);
+ if (!tdm)
+ return -ENOMEM;
+
+ ret = of_property_read_u32_array(np, propname, out_value, 4);
+ if (ret)
+ return ret;
+
+ tdm->tx_mask = out_value[0];
+ tdm->rx_mask = out_value[1];
+ tdm->slots = out_value[2];
+ tdm->slot_width = out_value[3];
+
+ dai->tdm = tdm;
+
+ return 0;
+}
+
+static int
asoc_simple_card_sub_parse_of(struct device_node *np,
unsigned int daifmt,
struct asoc_simple_dai *dai,
const struct device_node **p_node,
- const char **name)
+ const char **name,
+ struct device *dev)
{
struct device_node *node;
struct clk *clk;
@@ -91,6 +135,11 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
if (ret < 0)
goto parse_error;
+ /* parse tdm_slot */
+ ret = asoc_simple_card_of_parse_tdm_slot(np, dev, dai, "tdm-slot");
+ if (ret < 0)
+ goto parse_error;
+
/*
* bitclock-inversion, frame-inversion
* bitclock-master,frame-master
@@ -162,7 +211,8 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
ret = asoc_simple_card_sub_parse_of(np, priv->daifmt,
&priv->cpu_dai,
&dai_link->cpu_of_node,
- &dai_link->cpu_dai_name);
+ &dai_link->cpu_dai_name,
+ dev);
if (ret < 0)
return ret;
@@ -173,7 +223,8 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
ret = asoc_simple_card_sub_parse_of(np, priv->daifmt,
[PATCH Resend 4/8] ASoC: simple-card: Add snd_card's name parsing from DT node support
If the DT is used and the CPU DAI device has only one DAI, the card name will be like : ALSA device list: 0: 40031000.sai-sgtl5000 And this name maybe a little ugly to some customers, so here the card name parsing from DT node is supported. Signed-off-by: Xiubo Li --- sound/soc/generic/simple-card.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c index f38e56e..546b93d 100644 --- a/sound/soc/generic/simple-card.c +++ b/sound/soc/generic/simple-card.c @@ -140,6 +140,9 @@ static int asoc_simple_card_parse_of(struct device_node *node, char *name; int ret; + /* parsing the card name from DT */ + snd_soc_of_parse_card_name(&priv->snd_card, "simple-audio-card,name"); + /* get CPU/CODEC common format via simple-audio-card,format */ priv->daifmt = snd_soc_of_parse_daifmt(node, "simple-audio-card,") & (SND_SOC_DAIFMT_FORMAT_MASK | SND_SOC_DAIFMT_INV_MASK); @@ -184,7 +187,8 @@ static int asoc_simple_card_parse_of(struct device_node *node, GFP_KERNEL); sprintf(name, "%s-%s", dai_link->cpu_dai_name, dai_link->codec_dai_name); - priv->snd_card.name = name; + if (!priv->snd_card.name) + priv->snd_card.name = name; dai_link->name = dai_link->stream_name = name; /* simple-card assumes platform == cpu */ -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
On Thu, Jan 23, 2014 at 01:49:28PM +0800, Tang Chen wrote:
> This doesn't always happen. According to Dave, this happened once
> in about five boots. The backtrace is like the following:
>
> dump_stack
> panic
> ? numa_clear_kernel_node_hotplug
> __stack_chk_fail
> numa_clear_kernel_node_hotplug
> ? memblock_search_pfn_nid
> ? __early_pfn_to_nid
> numa_init
> x86_numa_init
> initmem_init
> setup_arch
> start_kernel
>
> This patch fix this problem by defining numa_kernel_nodes as a
> static global variable in __initdata area.
>
> diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> index 81b2750..ebefeb7 100644
> --- a/arch/x86/mm/numa.c
> +++ b/arch/x86/mm/numa.c
> @@ -562,10 +562,10 @@ static void __init numa_init_array(void)
> }
> }
>
> +static nodemask_t numa_kernel_nodes __initdata;
> static void __init numa_clear_kernel_node_hotplug(void)
> {
> int i, nid;
> -nodemask_t numa_kernel_nodes;
> unsigned long start, end;
> struct memblock_type *type = &memblock.reserved;
I'm surprised that this worked for anyone.
By my math, nodemask_t is 1024 longs, which should fill the whole stack.
Any idea why it only broke sometimes ?
There are other on-stack nodemask_t's in the tree too, why are they safe ?
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 6lowpan: add a license to 6lowpan_iphc module
From: Yann Droneaud Date: Wed, 22 Jan 2014 20:25:24 +0100 > Since commit 8df8c56a5abc, 6lowpan_iphc is a module of its own. > > Unfortunately, it lacks some infrastructure to behave like a > good kernel citizen: > > kernel: 6lowpan_iphc: module license 'unspecified' taints kernel. > kernel: Disabling lock debugging due to kernel taint > > This patch adds the basic MODULE_LICENSE(); with GPL license: > the code was copied from net/ieee802154/6lowpan.c which is GPL > and the module exports symbol with EXPORT_SYMBOL_GPL();. > > Cc: Jukka Rissanen > Cc: Alexander Aring > Cc: Marcel Holtmann > Signed-off-by: Yann Droneaud Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] net/neighbour: queue work on power efficient wq
From: Viresh Kumar Date: Wed, 22 Jan 2014 12:23:33 +0530 > Workqueue used in neighbour layer have no real dependency of scheduling these > on > the cpu which scheduled them. > > On a idle system, it is observed that an idle cpu wakes up many times just to > service this work. It would be better if we can schedule it on a cpu which the > scheduler believes to be the most appropriate one. > > This patch replaces normal workqueues with power efficient versions. This > doesn't change existing behavior of code unless CONFIG_WQ_POWER_EFFICIENT is > enabled. > > Signed-off-by: Viresh Kumar Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] net/ipv4: queue work on power efficient wq
From: Viresh Kumar Date: Wed, 22 Jan 2014 12:23:32 +0530 > Workqueue used in ipv4 layer have no real dependency of scheduling these on > the > cpu which scheduled them. > > On a idle system, it is observed that an idle cpu wakes up many times just to > service this work. It would be better if we can schedule it on a cpu which the > scheduler believes to be the most appropriate one. > > This patch replaces normal workqueues with power efficient versions. This > doesn't change existing behavior of code unless CONFIG_WQ_POWER_EFFICIENT is > enabled. > > Signed-off-by: Viresh Kumar Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug 67651] Bisected: Lots of fragmented mmaps cause gimp to fail in 3.12 after exceeding vm_max_map_count
On Wed, Jan 22, 2014 at 02:45:53PM -0800, Andy Lutomirski wrote: > > > > Thus when user space application track memory changes now it can detect > > if > > vma area is renewed. > > Presumably some path is failing to set VM_SOFTDIRTY, thus preventing mms > from being merged. > > That being said, this could cause vma blowups for programs that are > actually using this thing. Hi Andy, indeed, this could happen. The easiest way is to ignore softdirty bit when we're trying to merge vmas and set it one new merged. I think this should be correct. Once I finish I'll send the patch. Cyrill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 9/9] mm: keep page cache radix tree nodes in check
On Mon, Jan 20, 2014 at 06:17:37PM -0500, Johannes Weiner wrote:
> On Fri, Jan 17, 2014 at 11:05:17AM +1100, Dave Chinner wrote:
> > On Fri, Jan 10, 2014 at 01:10:43PM -0500, Johannes Weiner wrote:
> > > Previously, page cache radix tree nodes were freed after reclaim
> > > emptied out their page pointers. But now reclaim stores shadow
> > > entries in their place, which are only reclaimed when the inodes
> > > themselves are reclaimed. This is problematic for bigger files that
> > > are still in use after they have a significant amount of their cache
> > > reclaimed, without any of those pages actually refaulting. The shadow
> > > entries will just sit there and waste memory. In the worst case, the
> > > shadow entries will accumulate until the machine runs out of memory.
> > >
> > > To get this under control, the VM will track radix tree nodes
> > > exclusively containing shadow entries on a per-NUMA node list.
> > > Per-NUMA rather than global because we expect the radix tree nodes
> > > themselves to be allocated node-locally and we want to reduce
> > > cross-node references of otherwise independent cache workloads. A
> > > simple shrinker will then reclaim these nodes on memory pressure.
> > >
> > > A few things need to be stored in the radix tree node to implement the
> > > shadow node LRU and allow tree deletions coming from the list:
> >
> > Just a couple of things with the list_lru interfaces.
> >
> >
> > > @@ -123,9 +129,39 @@ static void page_cache_tree_delete(struct
> > > address_space *mapping,
> > >* same time and miss a shadow entry.
> > >*/
> > > smp_wmb();
> > > - } else
> > > - radix_tree_delete(&mapping->page_tree, page->index);
> > > + }
> > > mapping->nrpages--;
> > > +
> > > + if (!node) {
> > > + /* Clear direct pointer tags in root node */
> > > + mapping->page_tree.gfp_mask &= __GFP_BITS_MASK;
> > > + radix_tree_replace_slot(slot, shadow);
> > > + return;
> > > + }
> > > +
> > > + /* Clear tree tags for the removed page */
> > > + index = page->index;
> > > + offset = index & RADIX_TREE_MAP_MASK;
> > > + for (tag = 0; tag < RADIX_TREE_MAX_TAGS; tag++) {
> > > + if (test_bit(offset, node->tags[tag]))
> > > + radix_tree_tag_clear(&mapping->page_tree, index, tag);
> > > + }
> > > +
> > > + /* Delete page, swap shadow entry */
> > > + radix_tree_replace_slot(slot, shadow);
> > > + node->count--;
> > > + if (shadow)
> > > + node->count += 1U << RADIX_TREE_COUNT_SHIFT;
> > > + else
> > > + if (__radix_tree_delete_node(&mapping->page_tree, node))
> > > + return;
> > > +
> > > + /* Only shadow entries in there, keep track of this node */
> > > + if (!(node->count & RADIX_TREE_COUNT_MASK) &&
> > > + list_empty(&node->private_list)) {
> > > + node->private_data = mapping;
> > > + list_lru_add(&workingset_shadow_nodes, &node->private_list);
> > > + }
> >
> > You can't do this list_empty(&node->private_list) check safely
> > externally to the list_lru code - only time that entry can be
> > checked safely is under the LRU list locks. This is the reason that
> > list_lru_add/list_lru_del return a boolean to indicate is the object
> > was added/removed from the list - they do this list_empty() check
> > internally. i.e. the correct, safe way to do conditionally update
> > state iff the object was added to the LRU is:
> >
> > if (!(node->count & RADIX_TREE_COUNT_MASK)) {
> > if (list_lru_add(&workingset_shadow_nodes, &node->private_list))
> > node->private_data = mapping;
> > }
> >
> > > + radix_tree_replace_slot(slot, page);
> > > + mapping->nrpages++;
> > > + if (node) {
> > > + node->count++;
> > > + /* Installed page, can't be shadow-only anymore */
> > > + if (!list_empty(&node->private_list))
> > > + list_lru_del(&workingset_shadow_nodes,
> > > + &node->private_list);
> > > + }
> >
> > Same issue here:
> >
> > if (node) {
> > node->count++;
> > list_lru_del(&workingset_shadow_nodes, &node->private_list);
> > }
>
> All modifications to node->private_list happen under
> mapping->tree_lock, and modifications of a neighboring link should not
> affect the outcome of the list_empty(), so I don't think the lru lock
> is necessary.
>
> It would be cleaner to take it of course, but that would mean adding
> an unconditional NUMAnode-wide lock to every page cache population.
>
> > > static int __add_to_page_cache_locked(struct page *page,
> > > diff --git a/mm/list_lru.c b/mm/list_lru.c
> > > index 72f9decb0104..47a9faf4070b 100644
> > > --- a/mm/list_lru.c
> > > +++ b/mm/list_lru.c
> > > @@ -88,10 +88,18 @@ restart:
> > > ret = isolate(item, &nlru->lock, cb_arg);
> > > switch (ret) {
> > > case LRU_REMOVED:
> > > + case LRU_REMOVED_RETRY:
> > >
[patch] mm, compaction: ignore pageblock skip when manually invoking compaction
The cached pageblock hint should be ignored when triggering compaction
through /proc/sys/vm/compact_memory so all eligible memory is isolated.
Manually invoking compaction is known to be expensive, there's no need to
skip pageblocks based on heuristics (mainly for debugging).
Signed-off-by: David Rientjes
---
mm/compaction.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/compaction.c b/mm/compaction.c
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1177,6 +1177,7 @@ static void compact_node(int nid)
struct compact_control cc = {
.order = -1,
.sync = true,
+ .ignore_skip_hint = true,
};
__compact_pgdat(NODE_DATA(nid), &cc);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is it ok for deferrable timer wakeup the idle cpu?
On 23 January 2014 11:11, Lei Wen wrote: > On Wed, Jan 22, 2014 at 10:07 PM, Thomas Gleixner wrote: >> On Wed, 22 Jan 2014, Lei Wen wrote: >>> Recently I want to do the experiment for cpu isolation over 3.10 kernel. >>> But I find the isolated one is periodically waken up by IPI interrupt. >>> >>> By checking the trace, I find those IPI is generated by add_timer_on, >>> which would calls wake_up_nohz_cpu, and wake up the already idle cpu. >>> >>> With further checking, I find this timer is added by on_demand governor of >>> cpufreq. It would periodically check each cores' state. >>> The problem I see here is cpufreq_governor using INIT_DEFERRABLE_WORK >>> as the tool, while timer is made as deferrable anyway. >>> And what is more that cpufreq checking is very frequent. In my case, the >>> isolated cpu is wakenup by IPI every 5ms. >>> >>> So why kernel need to wake the remote processor when mount the deferrable >>> timer? As per my understanding, we'd better keep cpu as idle when use >>> the deferrable timer. >> >> Indeed, we can avoid the wakeup of the remote cpu when the timer is >> deferrable. > > Glad to hear that we could fix this unwanted wakeup. > Do you have related patches already? > >> >> Though you really want to figure out why the cpufreq governor is >> arming timers on other cores every 5ms. That smells like an utterly >> stupid approach. > > Not sure why cpufreq choose such frequent profiling over each cpu. > As my understanding, since kernel is smp, launching profiler over one cpu > would be enough... Hi Guys, So the first question is why cpufreq needs it and is it really stupid? Yes, it is stupid but that's how its implemented since a long time. It does so to get data about the load on CPUs, so that freq can be scaled up/down. Though there is a solution in discussion currently, which will take inputs from scheduler and so these background timers would go away. But we need to wait until that time. Now, why do we need that for every cpu, while that for a single cpu might be enough? The answer is cpuidle here: What if the cpu responsible for running timer goes to sleep? Who will evaluate the load then? And if we make this timer run on one cpu in non-deferrable mode then that cpu would be waken up again and again from idle. So, it was decided to have a per-cpu deferrable timer. Though to improve efficiency, once it is fired on any cpu, timer for all other CPUs are rescheduled, so that they don't fire before 5ms (sampling time).. I think below diff might get this fixed for you, though I am not sure if it breaks something else. Probably Thomas/Frederic can answer here. If this looks fine I will send it formally again: diff --git a/kernel/timer.c b/kernel/timer.c index accfd24..3a2c7fa 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -940,7 +940,8 @@ void add_timer_on(struct timer_list *timer, int cpu) * makes sure that a CPU on the way to stop its tick can not * evaluate the timer wheel. */ - wake_up_nohz_cpu(cpu); + if (!tbase_get_deferrable(timer->base)) + wake_up_nohz_cpu(cpu); spin_unlock_irqrestore(&base->lock, flags); } EXPORT_SYMBOL_GPL(add_timer_on); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtd: mtd_oobtest: fix verify errors due to incorrect use of prandom_bytes_state()
Hi, Akinobu Mita wrote: > 2014/1/23 Lothar Waßmann : > > Hi, > > > > Akinobu Mita wrote: > >> 2014/1/22 Lothar Waßmann : > >> > Hi, > >> > > >> > Is anyone taking care of this? > >> > > >> > Lothar Waßmann wrote: > >> >> When using prandom_bytes_state() it is critical to use the same block > >> >> size in all invocations that are to produce the same random sequence. > >> >> Otherwise the state of the PRNG will be out of sync if the blocksize > >> >> is not divisible by 4. > >> >> This leads to bogus verification errors in several tests which use > >> >> different block sizes to initialize the buffer for writing and > >> >> comparison. > >> >> > >> >> Signed-off-by: Lothar Waßmann > >> >> --- > >> >> drivers/mtd/tests/oobtest.c | 14 -- > >> >> 1 files changed, 12 insertions(+), 2 deletions(-) > >> >> > >> >> diff --git a/drivers/mtd/tests/oobtest.c b/drivers/mtd/tests/oobtest.c > >> >> index 2e9e2d1..72c7359 100644 > >> >> --- a/drivers/mtd/tests/oobtest.c > >> >> +++ b/drivers/mtd/tests/oobtest.c > >> >> @@ -213,8 +213,15 @@ static int verify_eraseblock_in_one_go(int ebnum) > >> >> int err = 0; > >> >> loff_t addr = ebnum * mtd->erasesize; > >> >> size_t len = mtd->ecclayout->oobavail * pgcnt; > >> >> + int i; > >> >> + > >> >> + for (i = 0; i < pgcnt; i++) > >> >> + prandom_bytes_state(&rnd_state, &writebuf[i * use_len], > >> >> + use_len); > >> >> + if (len % use_len) > >> >> + prandom_bytes_state(&rnd_state, &writebuf[i * use_len], > >> >> + len % use_len); > >> >> > >> >> - prandom_bytes_state(&rnd_state, writebuf, len); > >> >> ops.mode = MTD_OPS_AUTO_OOB; > >> >> ops.len = 0; > >> >> ops.retlen= 0; > >> > >> I would rather fix the use of prandom_bytes_state() in write_eraseblock() > >> than fix in verify_eraseblock_in_one_go(). > >> > > Why and how? > > I thought that it could reduce calls of prandom_bytes_state() and > it makes code simpler than increasing calls. > > > write_whole_device() (which calls write_eraseblock()) is used multiple > > times with different verification methods (all blocks in one go or each > > block individually). > > If prandom_state_bytes() in write_eraseblock() would be changed, that > > function would have to know, how the block are going to be checked > > lateron to know how to set up the writebuffer. > > Instead of calling prandom_bytes_state() in the for loop in > write_eraseblock(), call prandom_bytes_state() at once before going > into the loop and use correct offset in writebuf in the loop. > Although, we also need to fix verify_eraseblock() in the same way. > > Doesn't that fix this problem? > Of course one could fix it that way, but that would be a much more invasive change that also needs more testing. Lothar Waßmann -- ___ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | i...@karo-electronics.de ___ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] numa, mem-hotplug: Fix stack overflow in numa when seting kernel nodes to unhotpluggable.
Dave found that the kernel will hang during boot. This is because
the nodemask_t type stack variable numa_kernel_nodes is large enough
to overflow the stack.
This doesn't always happen. According to Dave, this happened once
in about five boots. The backtrace is like the following:
dump_stack
panic
? numa_clear_kernel_node_hotplug
__stack_chk_fail
numa_clear_kernel_node_hotplug
? memblock_search_pfn_nid
? __early_pfn_to_nid
numa_init
x86_numa_init
initmem_init
setup_arch
start_kernel
This patch fix this problem by defining numa_kernel_nodes as a
static global variable in __initdata area.
Reported-by: Dave Jones
Signed-off-by: Tang Chen
Tested-by: Gu Zheng
---
arch/x86/mm/numa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 81b2750..ebefeb7 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -562,10 +562,10 @@ static void __init numa_init_array(void)
}
}
+static nodemask_t numa_kernel_nodes __initdata;
static void __init numa_clear_kernel_node_hotplug(void)
{
int i, nid;
- nodemask_t numa_kernel_nodes;
unsigned long start, end;
struct memblock_type *type = &memblock.reserved;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] backlight: turn backlight on/off when necessary
On Wednesday, January 22, 2014 6:36 PM, Jani Nikula wrote: > On Mon, 20 Jan 2014, Liu Ying wrote: > > We don't have to turn backlight on/off everytime a blanking > > or unblanking event comes because the backlight status may > > have already been what we want. Another thought is that one > > backlight device may be shared by multiple framebuffers. We > > don't hope blanking one of the framebuffers may turn the > > backlight off for all the other framebuffers, since they are > > likely being active to display something. This patch adds > > some logics to record each framebuffer's backlight usage to > > determine the backlight device use count and whether the > > backlight should be turned on or off. To be more specific, > > only one unblank operation on a certain blanked framebuffer > > may increase the backlight device's use count by one, while > > one blank operation on a certain unblanked framebuffer may > > decrease the use count by one, because the userspace is > > likely to unblank a unblanked framebuffer or blank a blanked > > framebuffer. > > > > Signed-off-by: Liu Ying > > --- > > v1 can be found at https://lkml.org/lkml/2013/5/30/139 > > > > v1->v2: > > * Make the commit message be more specific about the condition > > in which backlight device use count can be increased/decreased. > > * Correct the setting for bd->props.fb_blank. > > > > drivers/video/backlight/backlight.c | 28 +--- > > include/linux/backlight.h |6 ++ > > 2 files changed, 27 insertions(+), 7 deletions(-) > > [.] > > Anything backlight worries me a little, and there are actually three > changes bundled into one patch here: > > 1. Changing bd->props.state and bd->props.fb_blank only when use_count >changes from 0->1 or 1->0. > > 2. Calling backlight_update_status() only with the above change, and not >on all notifier callbacks. > > 3. Setting bd->props.fb_blank always to either FB_BLANK_UNBLANK or >FB_BLANK_POWERDOWN instead of *(int *)evdata->data. > > The rationale in the commit message seems plausible, and AFAICT the code > does what it says on the box, so for that (and for that alone) you can > have my > > Reviewed-by: Jani Nikula > > *BUT* it would be laborous to figure out whether this change in > behaviour might regress some drivers. I'm just punting on that. And that > brings us back to the three changes above - in a bisect POV it might be > helpful to split the patch up. Up to the maintainers. I agree with Jani Nikula's opinion. Please split this patch into three patches as above mentioned. Best regards, Jingoo Han -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [media] s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks
Hi Swaminathan, On Thu, Jan 23, 2014 at 10:49 AM, swaminathan wrote: > Hi All, > Is there any review Comments for the patch "[PATCH] [media] s5p-mfc: Add > Horizontal and Vertical search range for Video Macro Blocks" > posted on 30-Dec-2013 ? > > Just a side note, please don’t top post and always reply as plain text. [Snip] > Subject: [PATCH] [media] s5p-mfc: Add Horizontal and Vertical search range > for Video Macro Blocks > > >> This patch adds Controls to set Horizontal and Vertical search range >> for Motion Estimation block for Samsung MFC video Encoders. >> >> Signed-off-by: Swami Nathan >> Signed-off-by: Amit Grover >> --- >> Documentation/DocBook/media/v4l/controls.xml| 14 + >> drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++ >> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 24 >> +++ >> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |8 ++-- >> drivers/media/v4l2-core/v4l2-ctrls.c| 14 + >> include/uapi/linux/v4l2-controls.h |2 ++ >> 6 files changed, 58 insertions(+), 6 deletions(-) >> This patch from the outset looks OK, but you need to split up into two, first adding a v4l control and second one using it up in the driver. Regards, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it ok for deferrable timer wakeup the idle cpu?
On Wed, Jan 22, 2014 at 10:07 PM, Thomas Gleixner wrote: > On Wed, 22 Jan 2014, Lei Wen wrote: >> Recently I want to do the experiment for cpu isolation over 3.10 kernel. >> But I find the isolated one is periodically waken up by IPI interrupt. >> >> By checking the trace, I find those IPI is generated by add_timer_on, >> which would calls wake_up_nohz_cpu, and wake up the already idle cpu. >> >> With further checking, I find this timer is added by on_demand governor of >> cpufreq. It would periodically check each cores' state. >> The problem I see here is cpufreq_governor using INIT_DEFERRABLE_WORK >> as the tool, while timer is made as deferrable anyway. >> And what is more that cpufreq checking is very frequent. In my case, the >> isolated cpu is wakenup by IPI every 5ms. >> >> So why kernel need to wake the remote processor when mount the deferrable >> timer? As per my understanding, we'd better keep cpu as idle when use >> the deferrable timer. > > Indeed, we can avoid the wakeup of the remote cpu when the timer is > deferrable. Glad to hear that we could fix this unwanted wakeup. Do you have related patches already? > > Though you really want to figure out why the cpufreq governor is > arming timers on other cores every 5ms. That smells like an utterly > stupid approach. Not sure why cpufreq choose such frequent profiling over each cpu. As my understanding, since kernel is smp, launching profiler over one cpu would be enough... Thanks, Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Deadlock between cpu_hotplug_begin and cpu_add_remove_lock
On 01/23/2014 07:59 AM, Rusty Russell wrote:
> "Srivatsa S. Bhat" writes:
>> On 01/22/2014 02:00 PM, Srivatsa S. Bhat wrote:
>>> Hi Paul,
>
> I find an old patch for register_allcpu_notifier(), but the "bool
> replay_history" should be eliminated (always true): it's too weird.
>
Sorry, I didn't get this part. Why do you say that replay_history
will always be true?
replay_history will be set to true whenever the caller wants to
get notified of CPU_UP_PREPARE and CPU_ONLINE notifications for the
already online CPUs, or wants to run a custom setup-routine of its
own. And it will be false whenever the caller simply wants to just
register the callback.
Note that passing NULL for the setup-routine, by itself isn't enough
to make a decision. NULL + replay_history == True will invoke the normal
CPU_UP_PREPARE/CPU_ONLINE notifiers for the already online CPUs before
registering the callback. NULL + replay_history == False will just
register the callback and do nothing else.
> Then we should get rid of register_cpu_notifier, or at least hide it.
>
Why? Isn't it easier to use (since you don't have to pass 2 additional
parameters)? I see register_allcpu_notifier (or whatever better name
we can give it), as an API for special cases where there is something
more to be done than just registering the callback. And register_cpu_notifier
will continue to be the API for the regular case when the caller wants
to just register the callback. This latter case is the majority in the
kernel. So I don't think eliminating the regular API would be a good idea.
By the way, I'm still tempted to try out the simpler-looking alternative
idea of exporting cpu_maps_update_begin() and cpu_maps_update_done()
and then mandating that the callers do:
cpu_maps_update_begin();
for_each_online_cpu(cpu) {
...
}
__register_cpu_notifier(); // this doesn't take the add_remove_lock
cpu_maps_update_done();
I'm working on a patchset that does this and performs a tree-wide
conversion. Please let me know if you have any objections to exporting
cpu_maps_update_begin/done() in this manner.
I thought I'd give this solution a try first, before going to the much
fancier register_allcpu_notifier() method.
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes
On Wed, Jan 22, 2014 at 06:46:11PM -0800, David Lang wrote: > It's extremely unlikely that drive manufacturers will produce drives > that won't work with any existing OS, so they are going to support > smaller writes in firmware. If they don't, they won't be able to > sell their drives to anyone running existing software. Given the > Enterprise software upgrade cycle compared to the expanding storage > needs, whatever they ship will have to work on OS and firmware > releases that happened several years ago. I've been talking to a number of HDD vendors, and while most of the discussions has been about SMR, the topic of 64k sectors did come up recently. In the opinion of at least one drive vendor, the pressure or 64k sectors will start increasing (roughly paraphrasing that vendor's engineer, "it's a matter of physics"), and it might not be surprising that in 2 or 3 years, we might start seing drives with 64k sectors. Like with 4k sector drives, it's likely that at least initial said drives will have an emulation mode where sub-64k writes will require a read-modify-write cycle. What I told that vendor was that if this were the case, he should seriously consider submitting a topic proposal to the LSF/MM, since if he wants those drives to be well supported, we need to start thinking about what changes might be necessary at the VM and FS layers now. So hopefully we'll see a topic proposal from that HDD vendor in the next couple of days. The bottom line is that I'm pretty well convinced that like SMR drives, 64k sector drives will be coming, and it's not something we can duck. It might not come as quickly as the HDD vendor community might like --- I remember attending an IDEMA conference in 2008 where they confidently predicted that 4k sector drives would be the default in 2 years, and it took a wee bit longer than that. But nevertheless, looking at the most likely roadmap and trajectory of hard drive technology, these are two things that will very likely be coming down the pike, and it would be best if we start thinking about how to engage with these changes constructively sooner rather than putting it off and then getting caught behind the eight-ball later. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig errors
On Wed, Jan 22, 2014 at 5:56 PM, Russell King - ARM Linux wrote: > On Wed, Jan 22, 2014 at 05:54:29PM +0530, Prabhakar Lad wrote: >> Hi Russell, >> >> On Fri, Jan 17, 2014 at 1:07 PM, Prabhakar Lad >> wrote: >> > Hi, >> > >> > On Linux-next branch I see following errors for davinci_all_defconfig >> > & da8xx_omapl_defconfig configs, >> > >> > arch/arm/Kconfig:1966:error: recursive dependency detected! >> > arch/arm/Kconfig:1966:symbol ZBOOT_ROM depends on AUTO_ZRELADDR >> > arch/arm/Kconfig:2154:symbol AUTO_ZRELADDR is selected by ZBOOT_ROM >> > # >> > # configuration written to .config >> > # >> > >> I am seeing this errors on linux-next, with your recent patch, >> "[PATCH] Fix select-induced Kconfig warning for ZBOOT_ROM" >> and strangely I see that AUTO_ZRELADDR doesnt select ZBOOT_ROM >> but still an error. >> >> Note: For the davinci configs CONFIG_AUTO_ZRELADDR is not set and >> CONFIG_ZBOOT_ROM_TEXT=0x0, CONFIG_ZBOOT_ROM_BSS=0x0 > > I've killed off the "select AUTO_ZRELADDR if !ZBOOT_ROM" in the IMX > Kconfig now, so when linux-next picks up my tree, that should be gone. > Thanks that helps. Regards, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 9/9] mm: keep page cache radix tree nodes in check
On Wed, Jan 22, 2014 at 01:42:17PM -0500, Johannes Weiner wrote:
> On Mon, Jan 13, 2014 at 04:39:47PM +0900, Minchan Kim wrote:
> > On Fri, Jan 10, 2014 at 01:10:43PM -0500, Johannes Weiner wrote:
> > > Previously, page cache radix tree nodes were freed after reclaim
> > > emptied out their page pointers. But now reclaim stores shadow
> > > entries in their place, which are only reclaimed when the inodes
> > > themselves are reclaimed. This is problematic for bigger files that
> > > are still in use after they have a significant amount of their cache
> > > reclaimed, without any of those pages actually refaulting. The shadow
> > > entries will just sit there and waste memory. In the worst case, the
> > > shadow entries will accumulate until the machine runs out of memory.
> > >
> > > To get this under control, the VM will track radix tree nodes
> > > exclusively containing shadow entries on a per-NUMA node list.
> > > Per-NUMA rather than global because we expect the radix tree nodes
> > > themselves to be allocated node-locally and we want to reduce
> > > cross-node references of otherwise independent cache workloads. A
> > > simple shrinker will then reclaim these nodes on memory pressure.
> > >
> > > A few things need to be stored in the radix tree node to implement the
> > > shadow node LRU and allow tree deletions coming from the list:
> > >
> > > 1. There is no index available that would describe the reverse path
> > >from the node up to the tree root, which is needed to perform a
> > >deletion. To solve this, encode in each node its offset inside the
> > >parent. This can be stored in the unused upper bits of the same
> > >member that stores the node's height at no extra space cost.
> > >
> > > 2. The number of shadow entries needs to be counted in addition to the
> > >regular entries, to quickly detect when the node is ready to go to
> > >the shadow node LRU list. The current entry count is an unsigned
> > >int but the maximum number of entries is 64, so a shadow counter
> > >can easily be stored in the unused upper bits.
> > >
> > > 3. Tree modification needs tree lock and tree root, which are located
> > >in the address space, so store an address_space backpointer in the
> > >node. The parent pointer of the node is in a union with the 2-word
> > >rcu_head, so the backpointer comes at no extra cost as well.
> > >
> > > 4. The node needs to be linked to an LRU list, which requires a list
> > >head inside the node. This does increase the size of the node, but
> > >it does not change the number of objects that fit into a slab page.
> > >
> > > Signed-off-by: Johannes Weiner
> > > ---
> > > include/linux/list_lru.h | 2 +
> > > include/linux/mmzone.h | 1 +
> > > include/linux/radix-tree.h | 32 +---
> > > include/linux/swap.h | 1 +
> > > lib/radix-tree.c | 36 --
> > > mm/filemap.c | 77 +++--
> > > mm/list_lru.c | 8 +++
> > > mm/truncate.c | 20 +++-
> > > mm/vmstat.c| 1 +
> > > mm/workingset.c| 121
> > > +
> > > 10 files changed, 259 insertions(+), 40 deletions(-)
> > >
> > > diff --git a/include/linux/list_lru.h b/include/linux/list_lru.h
> > > index 3ce541753c88..b02fc233eadd 100644
> > > --- a/include/linux/list_lru.h
> > > +++ b/include/linux/list_lru.h
> > > @@ -13,6 +13,8 @@
> > > /* list_lru_walk_cb has to always return one of those */
> > > enum lru_status {
> > > LRU_REMOVED,/* item removed from list */
> > > + LRU_REMOVED_RETRY, /* item removed, but lock has been
> > > +dropped and reacquired */
> > > LRU_ROTATE, /* item referenced, give another pass */
> > > LRU_SKIP, /* item cannot be locked, skip */
> > > LRU_RETRY, /* item not freeable. May drop the lock
> > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > > index 118ba9f51e86..8cac5a7ef7a7 100644
> > > --- a/include/linux/mmzone.h
> > > +++ b/include/linux/mmzone.h
> > > @@ -144,6 +144,7 @@ enum zone_stat_item {
> > > #endif
> > > WORKINGSET_REFAULT,
> > > WORKINGSET_ACTIVATE,
> > > + WORKINGSET_NODERECLAIM,
> > > NR_ANON_TRANSPARENT_HUGEPAGES,
> > > NR_FREE_CMA_PAGES,
> > > NR_VM_ZONE_STAT_ITEMS };
> > > diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
> > > index 13636c40bc42..33170dbd9db4 100644
> > > --- a/include/linux/radix-tree.h
> > > +++ b/include/linux/radix-tree.h
> > > @@ -72,21 +72,37 @@ static inline int radix_tree_is_indirect_ptr(void
> > > *ptr)
> > > #define RADIX_TREE_TAG_LONGS \
> > > ((RADIX_TREE_MAP_SIZE + BITS_PER_LONG - 1) / BITS_PER_LONG)
> > >
> > > +#define RADIX_TREE_INDEX_BITS (8 /* CHAR_BIT */ * sizeof(unsigned long))
> > > +#define RADIX_TREE_MAX_PATH (DIV_ROUND_UP(RADIX_TREE_INDEX_BIT
Re: [PATCH] [media] s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks
Hi All,
Is there any review Comments for the patch "[PATCH] [media] s5p-mfc: Add
Horizontal and Vertical search range for Video Macro Blocks"
posted on 30-Dec-2013 ?
Regards,
Swaminathan
--
From: "Amit Grover"
Sent: Monday, December 30, 2013 4:13 PM
To: ; ;
; ;
; ;
; ; ;
Cc: ; ;
; ; ;
; ; "Swami Nathan"
Subject: [PATCH] [media] s5p-mfc: Add Horizontal and Vertical search range
for Video Macro Blocks
This patch adds Controls to set Horizontal and Vertical search range
for Motion Estimation block for Samsung MFC video Encoders.
Signed-off-by: Swami Nathan
Signed-off-by: Amit Grover
---
Documentation/DocBook/media/v4l/controls.xml| 14 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 24
+++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |8 ++--
drivers/media/v4l2-core/v4l2-ctrls.c| 14 +
include/uapi/linux/v4l2-controls.h |2 ++
6 files changed, 58 insertions(+), 6 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 7a3b49b..70a0f6f 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2258,6 +2258,20 @@ Applicable to the MPEG1, MPEG2, MPEG4
encoders.
VBV buffer control.
+
+
+ spanname="id">V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE
+ integer
+ Sets the Horizontal search
range for Video Macro blocks.
+
+
+
+
+ spanname="id">V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE
+ integer
+ Sets the Vertical search range
for Video Macro blocks.
+
+
spanname="id">V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 6920b54..f2c13c3 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -430,6 +430,8 @@ struct s5p_mfc_vp8_enc_params {
struct s5p_mfc_enc_params {
u16 width;
u16 height;
+ u32 horz_range;
+ u32 vert_range;
u16 gop_size;
enum v4l2_mpeg_video_multi_slice_mode slice_mode;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4ff3b6c..a02e7b8 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -208,6 +208,24 @@ static struct mfc_control controls[] = {
.default_value = 0,
},
{
+ .id = V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "horizontal search range of video macro block",
+ .minimum = 16,
+ .maximum = 128,
+ .step = 16,
+ .default_value = 32,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "vertical search range of video macro block",
+ .minimum = 16,
+ .maximum = 128,
+ .step = 16,
+ .default_value = 32,
+ },
+ {
.id = V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE,
.type = V4L2_CTRL_TYPE_INTEGER,
.minimum = 0,
@@ -1377,6 +1395,12 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl
*ctrl)
case V4L2_CID_MPEG_VIDEO_VBV_SIZE:
p->vbv_size = ctrl->val;
break;
+ case V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE:
+ p->horz_range = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE:
+ p->vert_range = ctrl->val;
+ break;
case V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE:
p->codec.h264.cpb_size = ctrl->val;
break;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 461358c..47e1807 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -727,14 +727,10 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx
*ctx)
WRITEL(reg, S5P_FIMV_E_RC_CONFIG_V6);
/* setting for MV range [16, 256] */
- reg = 0;
- reg &= ~(0x3FFF);
- reg = 256;
+ reg = (p->horz_range & 0x3fff); /* conditional check in app */
WRITEL(reg, S5P_FIMV_E_MV_HOR_RANGE_V6);
- reg = 0;
- reg &= ~(0x3FFF);
- reg = 256;
+ reg = (p->vert_range & 0x3fff); /* conditional check in app */
WRITEL(reg, S5P_FIMV_E_MV_VER_RANGE_V6);
WRITEL(0x0, S5P_FIMV_E_FRAME_INSERTION_V6);
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index fb46790..7cf23d5 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -735,6 +735,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_DEC_PTS: return "Video Decoder PTS";
case V4L2_CID_MPEG_VIDEO_DEC_FRAME: return "Video Decoder Frame Count";
case V4L2_CID_MPEG_VIDEO_VBV_DELAY: return "Initial Delay for VBV
Control";
+ case V4L2_CID_MPEG_VIDEO_HORZ_SEARCH_RANGE: return "hor search range of
video MB";
+ case V4L2_CID_MPEG_VIDEO_VERT_SEARCH_RANGE: return "vert search range of
video MB";
case V4L2_CID_MPEG_VIDEO_REPEAT
Re: [patch 5/9] mm + fs: prepare for non-page entries in page cache radix trees
Hi Hannes,
On Wed, Jan 22, 2014 at 12:47:44PM -0500, Johannes Weiner wrote:
> On Mon, Jan 13, 2014 at 11:01:32AM +0900, Minchan Kim wrote:
> > On Fri, Jan 10, 2014 at 01:10:39PM -0500, Johannes Weiner wrote:
> > > shmem mappings already contain exceptional entries where swap slot
> > > information is remembered.
> > >
> > > To be able to store eviction information for regular page cache,
> > > prepare every site dealing with the radix trees directly to handle
> > > entries other than pages.
> > >
> > > The common lookup functions will filter out non-page entries and
> > > return NULL for page cache holes, just as before. But provide a raw
> > > version of the API which returns non-page entries as well, and switch
> > > shmem over to use it.
> > >
> > > Signed-off-by: Johannes Weiner
> > Reviewed-by: Minchan Kim
>
> Thanks, Minchan!
>
> > > @@ -890,6 +973,73 @@ repeat:
> > > EXPORT_SYMBOL(find_or_create_page);
> > >
> > > /**
> > > + * __find_get_pages - gang pagecache lookup
> > > + * @mapping: The address_space to search
> > > + * @start: The starting page index
> > > + * @nr_pages:The maximum number of pages
> > > + * @pages: Where the resulting pages are placed
> >
> > where is @indices?
>
> Fixed :)
>
> > > @@ -894,6 +894,53 @@ EXPORT_SYMBOL(__pagevec_lru_add);
> > >
> > > /**
> > > * pagevec_lookup - gang pagecache lookup
> >
> > __pagevec_lookup?
> >
> > > + * @pvec:Where the resulting entries are placed
> > > + * @mapping: The address_space to search
> > > + * @start: The starting entry index
> > > + * @nr_pages:The maximum number of entries
> >
> > missing @indices?
> >
> > > + *
> > > + * pagevec_lookup() will search for and return a group of up to
> > > + * @nr_pages pages and shadow entries in the mapping. All entries are
> > > + * placed in @pvec. pagevec_lookup() takes a reference against actual
> > > + * pages in @pvec.
> > > + *
> > > + * The search returns a group of mapping-contiguous entries with
> > > + * ascending indexes. There may be holes in the indices due to
> > > + * not-present entries.
> > > + *
> > > + * pagevec_lookup() returns the number of entries which were found.
> >
> > __pagevec_lookup
>
> Yikes, all three fixed.
>
> > > @@ -22,6 +22,22 @@
> > > #include
> > > #include "internal.h"
> > >
> > > +static void clear_exceptional_entry(struct address_space *mapping,
> > > + pgoff_t index, void *entry)
> > > +{
> > > + /* Handled by shmem itself */
> > > + if (shmem_mapping(mapping))
> > > + return;
> > > +
> > > + spin_lock_irq(&mapping->tree_lock);
> > > + /*
> > > + * Regular page slots are stabilized by the page lock even
> > > + * without the tree itself locked. These unlocked entries
> > > + * need verification under the tree lock.
> > > + */
> >
> > Could you explain why repeated spin_lock with irq disabled isn't problem
> > in truncation path?
>
> To modify the cache tree, we have to take the IRQ-safe tree_lock, this
> is no different than removing a page (see truncate_complete_page).
I meant we can do batch irq_[lock|unlock] part with periodic irq release
because clear_exceptional_entry is always called with gang pagecache
lookup.
Just a comment about optimiztation so it shouldn't be critical for merging
and we could do in future if it's really problem for scalability.
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Regression on next-20140116 [Was: [PATCH 3/3 v4] usb: chipidea: hw_phymode_configure moved before ci_usb_phy_init]
On Thursday, January 23, 2014 09:22 AM, Peter Chen wrote: On Wed, Jan 22, 2014 at 10:41:33PM +0100, Uwe Kleine-König wrote: Hello, On Wed, Jan 22, 2014 at 10:49:51AM +0100, Uwe Kleine-König wrote: On Tue, Dec 03, 2013 at 04:01:50PM +0800, Chris Ruehl wrote: usb: chipidea: hw_phymode_configure moved before ci_usb_phy_init hw_phymode_configure configures the PORTSC registers and allow the following phy_inits to operate on the right parameters. This fix a problem where the UPLI (ISP1504) could not detected, because the Viewport was not available and read the viewport return 0's only. This patch (or a later revision of it to be more exact) made it into mainline as cd0b42c2a6d2. On an i.MX27 based machine I'm hitting an oops (see below) on next-20140116 + a few patches. (I didn't switch to 3.13+ yet, as I think not everything I need has landed there.) The oops goes away (and still better, lsusb reports my connected devices instead of "unable to initialize libusb: -99") when I do at least one of the following: - set CONFIG_USB_CHIPIDEA=y instead of =m - revert commit cd0b42c2a6d2 (usb: chipidea: put hw_phymode_configure before ci_usb_phy_init) I debugged that a bit further and the problem is that hw_phymode_configure depends on the phy's clk being enabled (i.e. usb_ipg_gate) and this is only enforced in ci_usb_phy_init (via usb_phy_init -> usb_gen_phy_init). When CONFIG_USB_CHIPIDEA=y the init call to disable all unused clocks wasn't run yet and so the clock is still on as this is the boot default. Hi Uwe, I am a little puzzled at your platform - Which phy you have used? ulpi phy ,internal phy or other external phy? - If you use ulpi phy, why you still need to use nop phy driver? Besides, according to chris patch, the ulpi can only be visited after hw_phymode_configure? - Do you have some hardware related operation at phy's probe? If it exists, why not move it to phy->init? Peter Peter, I think thats my fault, I send Uwe my patches which call the phy-ulpi from the nop driver in order to get the ISP1504 running with my board. Its obversely wrong to call an other driver from the nop see: [PATCH 3/3] usb: phy-generic: Add ULPI VBUS support and the concerns from Heikki (mail-list linux-usb) Uwe we may work together on this. Chris Considering that it's already late today and that I don't know the chipidea driver I'm sure there are people who can come up with a better patch with less effort than me. Any volunteers? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Deadlock between cpu_hotplug_begin and cpu_add_remove_lock
"Srivatsa S. Bhat" writes: > On 01/22/2014 02:00 PM, Srivatsa S. Bhat wrote: >> Hi Paul, I find an old patch for register_allcpu_notifier(), but the "bool replay_history" should be eliminated (always true): it's too weird. Then we should get rid of register_cpu_notifier, or at least hide it. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tracing: Use task_nice() in function __update_max_tr() to get the nice value of task.
On 01/22/2014 11:00 PM, Steven Rostedt wrote: Bah, I just noticed that TASK_NICE is in kernel/sched/sched.h not include/linux/sched.h Peter, is there a reason that task_nice() is not a static inline in sched.h and have these macros there too? They only reference fields in task_struct that are already defined there. I don't see why they need to be private to kernel/sched. Agree. These macros are useful to other modules out of kernel/sched. But they are private to kernel/sched currently. If we move them to include/linux/sched.h, I will use TASK_NICE in this patch. -- Steve Thanks, -- Steve max_data->policy = tsk->policy; max_data->rt_priority = tsk->rt_priority; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Internal error: Oops: 17 [#1] ARM
Thanks! I will try it tomorrow. Regards, John Sent from my iPhone > On Jan 22, 2014, at 7:46 PM, walimis wrote: > >> On Wed, Jan 22, 2014 at 07:28:55PM -0800, John Tobias wrote: >> Hi Liming, >> >> Yes, I am using 4.8.1. I switched back to 4.7.3 and will test it again >> if I can re-produce it. > > Hi, > > Or you can use the latest linaro 4.8.x toolchain, which has been applied that > patch: > > http://releases.linaro.org/13.12/components/toolchain/binaries/ > > Please select this one to try: > > gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux.tar.bz2 > > Liming Wang >> >> Regards, >> >> john >> >>> On Wed, Jan 22, 2014 at 7:01 PM, walimis wrote: On Wed, Jan 22, 2014 at 08:23:36AM -0800, John Tobias wrote: Hello all, I am using 3.13-rc1 kernel on iMX6SL processor. My filesystem is in eMMC running SDR50. Is anyone here encountered these problem and if there's any existing patch that I can get?. >>> hi, >>> >>> Do you use gcc 4.8.1? If so, maybe you should look at following link >>> to see whether it's a similar issue. >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 >>> >>> Liming Wang >>> Regards, john [ 1552.394899] Unable to handle kernel NULL pointer dereference at virtual address 0037 [ 1552.403034] pgd = beef4000 [ 1552.405855] [0037] *pgd=bef60831, *pte=, *ppte= [ 1552.412245] Internal error: Oops: 17 [#1] ARM [ 1552.416627] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(O) [ 1552.422249] CPU: 0 PID: 232 Comm: commsd Tainted: G O 3.13.0-rc1 #7 [ 1552.429409] task: bfbc7500 ti: bec96000 task.ti: bec96000 [ 1552.434844] PC is at lookup_fast+0x5c/0x318 [ 1552.439067] LR is at mark_held_locks+0x78/0x13c [ 1552.443622] pc : [<80101184>]lr : [<80056e48>]psr: a00f0013 [ 1552.443622] sp : bec97d88 ip : 00666e6f fp : bec97ddc [ 1552.455124] r10: r9 : bec97e08 r8 : 80102d94 [ 1552.460370] r7 : bec97e60 r6 : bf133ac8 r5 : bec97e60 r4 : bec97e00 [ 1552.466918] r3 : bee4f01d r2 : r1 : r0 : [ 1552.473471] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 1552.480629] Control: 10c53c7d Table: beef4059 DAC: 0015 [ 1552.486397] Process commsd (pid: 232, stack limit = 0xbec96238) [ 1552.492341] Stack: (0xbec97d88 to 0xbec98000) [ 1552.496728] 7d80: 80102b94 80057108 bfb95310 bf133ac8 bf15f4e8 bfb95310 [ 1552.504936] 7da0: c08bb14d bee4f015 0008 bfbc7500 bec97e08 0041 [ 1552.513142] 7dc0: bec97e60 bec96020 bec96000 bec97e3c bec97de0 80102d94 80101134 [ 1552.521347] 7de0: bec97df8 800d982c bec96018 0010 bec97e00 bec97e08 [ 1552.529553] 7e00: 8026e25c 800d97e8 bee4f000 0ff0 80d4e3a4 0001 bee4f000 bec97e60 [ 1552.537758] 7e20: ff9c ff9c bec96000 bec97e5c bec97e40 801033bc 80102c70 [ 1552.545964] 7e40: bee4f000 0001 bec97e60 bec97f00 bec97ee4 bec97e60 80105dc0 80103398 [ 1552.554170] 7e60: bfb95310 bf133ac8 c08bb14d 000b bee4f015 8005992c bfb95310 bf133398 [ 1552.562375] 7e80: bf15f4e8 0041 0002 008a 600f0013 bec96000 [ 1552.570581] 7ea0: ffea bf8c1840 807b4430 80115444 801156e4 8011563c 0008 [ 1552.578786] 7ec0: bec97f04 733fe4e0 0001 ff9c 757e3810 bec97f40 bec97efc bec97ee8 [ 1552.586991] 7ee0: 80105e0c 80105d68 bc950fe0 bec97f2c bec97f00 800faf64 80105df4 [ 1552.595196] 7f00: 801156e4 80115420 bec97f54 733fe4e0 733ff8f0 733fe61c 00c3 8000f504 [ 1552.603402] 7f20: bec97f3c bec97f30 800fafe0 800faf1c bec97fa4 bec97f40 800fb71c 800fafc4 [ 1552.611608] 7f40: 8000f310 bfbc7500 733fe550 8000f458 733fe61c 00c3 bec97f84 bec97f68 [ 1552.619813] 7f60: 80056f28 800a0270 733fe550 733ff8f0 733fe61c 00c3 bec97f94 bec97f88 [ 1552.628019] 7f80: 80057110 80056f18 bec97f98 8000f458 733fe550 bec97fa8 [ 1552.636226] 7fa0: 8000f280 800fb704 733fe550 733ff8f0 757e3810 733fe4e0 733fe550 0003 [ 1552.644431] 7fc0: 733fe550 733ff8f0 733fe61c 00c3 0002 733fe92c 0200 [ 1552.652636] 7fe0: 00c3 733fe4d8 7579b7e5 7572e276 200f0030 757e3810 bfffd821 bfffdc21 [ 1552.660828] Backtrace: [ 1552.663343] [<80101128>] (lookup_fast+0x0/0x318) from [<80102d94>] (path_lookupat+0x130/0x728) [ 1552.671994] [<80102c64>] (path_lookupat+0x0/0x728) from [<801033bc>] (filename_lookup.isra.40+0x30/0x70) [ 1552.681515] [<8010338c>] (filename_lookup.isra.40+0x0/0x70) from [<80105dc0>] (user_path_at_empty+0x64/0x8c) [ 1552.691361] r7:bec97f00 r6:bec97e60 r5:0001 r4:bee4f000 [ 1552.697163] [<80105d5
linux-next: manual merge of the userns tree with the mips tree
Hi Eric,
Today's linux-next merge of the userns tree got conflicts in
arch/mips/include/asm/vpe.h and arch/mips/kernel/vpe.c between commits
1a2a6d7e8816 ("MIPS: APRP: Split VPE loader into separate files") and
5792bf643865 ("MIPS: APRP: Code formatting clean-ups") from the mips tree
and commit f58437f1f916 ("MIPS: VPE: Remove vpe_getuid and vpe_getgid")
from the userns tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/mips/include/asm/vpe.h
index e0684f5f0054,0880fe8809b1..
--- a/arch/mips/include/asm/vpe.h
+++ b/arch/mips/include/asm/vpe.h
@@@ -9,88 -18,7 +9,87 @@@
#ifndef _ASM_VPE_H
#define _ASM_VPE_H
+#include
+#include
+#include
+#include
+
+#define VPE_MODULE_NAME "vpe"
+#define VPE_MODULE_MINOR 1
+
+/* grab the likely amount of memory we will need. */
+#ifdef CONFIG_MIPS_VPE_LOADER_TOM
+#define P_SIZE (2 * 1024 * 1024)
+#else
+/* add an overhead to the max kmalloc size for non-striped symbols/etc */
+#define P_SIZE (256 * 1024)
+#endif
+
+#define MAX_VPES 16
+#define VPE_PATH_MAX 256
+
+static inline int aprp_cpu_index(void)
+{
+#ifdef CONFIG_MIPS_CMP
+ return setup_max_cpus;
+#else
+ extern int tclimit;
+ return tclimit;
+#endif
+}
+
+enum vpe_state {
+ VPE_STATE_UNUSED = 0,
+ VPE_STATE_INUSE,
+ VPE_STATE_RUNNING
+};
+
+enum tc_state {
+ TC_STATE_UNUSED = 0,
+ TC_STATE_INUSE,
+ TC_STATE_RUNNING,
+ TC_STATE_DYNAMIC
+};
+
+struct vpe {
+ enum vpe_state state;
+
+ /* (device) minor associated with this vpe */
+ int minor;
+
+ /* elfloader stuff */
+ void *load_addr;
+ unsigned long len;
+ char *pbuffer;
+ unsigned long plen;
- unsigned int uid, gid;
+ char cwd[VPE_PATH_MAX];
+
+ unsigned long __start;
+
+ /* tc's associated with this vpe */
+ struct list_head tc;
+
+ /* The list of vpe's */
+ struct list_head list;
+
+ /* shared symbol address */
+ void *shared_ptr;
+
+ /* the list of who wants to know when something major happens */
+ struct list_head notify;
+
+ unsigned int ntcs;
+};
+
+struct tc {
+ enum tc_state state;
+ int index;
+
+ struct vpe *pvpe; /* parent VPE */
+ struct list_head tc;/* The list of TC's with this VPE */
+ struct list_head list; /* The global list of tc's */
+};
+
struct vpe_notifications {
void (*start)(int vpe);
void (*stop)(int vpe);
@@@ -98,36 -26,10 +97,34 @@@
struct list_head list;
};
+struct vpe_control {
+ spinlock_t vpe_list_lock;
+ struct list_head vpe_list; /* Virtual processing elements */
+ spinlock_t tc_list_lock;
+ struct list_head tc_list; /* Thread contexts */
+};
+
+extern unsigned long physical_memsize;
+extern struct vpe_control vpecontrol;
+extern const struct file_operations vpe_fops;
+
+int vpe_notify(int index, struct vpe_notifications *notify);
+
+void *vpe_get_shared(int index);
- int vpe_getuid(int index);
- int vpe_getgid(int index);
+char *vpe_getcwd(int index);
+
+struct vpe *get_vpe(int minor);
+struct tc *get_tc(int index);
+struct vpe *alloc_vpe(int minor);
+struct tc *alloc_tc(int index);
+void release_vpe(struct vpe *v);
-extern int vpe_notify(int index, struct vpe_notifications *notify);
+void *alloc_progmem(unsigned long len);
+void release_progmem(void *ptr);
-extern void *vpe_get_shared(int index);
-extern char *vpe_getcwd(int index);
+int __weak vpe_run(struct vpe *v);
+void cleanup_tc(struct tc *tc);
+int __init vpe_module_init(void);
+void __exit vpe_module_exit(void);
#endif /* _ASM_VPE_H */
diff --cc arch/mips/kernel/vpe.c
index 42d3ca08bd28,2d5c142bad67..
--- a/arch/mips/kernel/vpe.c
+++ b/arch/mips/kernel/vpe.c
@@@ -899,35 -1262,14 +896,13 @@@ void *vpe_get_shared(int index
return v->shared_ptr;
}
-
EXPORT_SYMBOL(vpe_get_shared);
- int vpe_getuid(int index)
- {
- struct vpe *v = get_vpe(index);
-
- if (v == NULL)
- return -1;
-
- return v->uid;
- }
- EXPORT_SYMBOL(vpe_getuid);
-
- int vpe_getgid(int index)
- {
- struct vpe *v = get_vpe(index);
-
- if (v == NULL)
- return -1;
-
- return v->gid;
- }
- EXPORT_SYMBOL(vpe_getgid);
-
int vpe_notify(int index, struct vpe_notifications *notify)
{
- struct vpe *v;
+ struct vpe *v = get_vpe(index);
- if ((v = get_vpe(index)) == NULL)
+ if (v == NULL)
return -1;
list_add(¬ify->list, &v->notify);
pgpclBr1_jBTi.pgp
Description: PGP signature
Re: [PATCH] tracing: Use task_nice() in function __update_max_tr() to get the nice value of task.
On Wed, 22 Jan 2014 22:56:32 -0500 Steven Rostedt wrote: > On Wed, 22 Jan 2014 17:41:45 -0500 > Dongsheng Yang wrote: > > > There is already a function named task_nice in sched.h to get the nice value > > of task_struct. We can use it in __update_max_tr() rather than calculate it > > manually. > > > > Signed-off-by: Dongsheng Yang > > --- > > kernel/trace/trace.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > > index 9d20cd9..ec149b4 100644 > > --- a/kernel/trace/trace.c > > +++ b/kernel/trace/trace.c > > @@ -970,7 +970,7 @@ __update_max_tr(struct trace_array *tr, struct > > task_struct *tsk, int cpu) > > else > > max_data->uid = task_uid(tsk); > > > > - max_data->nice = tsk->static_prio - 20 - MAX_RT_PRIO; > > + max_data->nice = task_nice(tsk); > > Except that's a function call in a critical path. Switch it to > TASK_NICE(), and I'll take the patch. Bah, I just noticed that TASK_NICE is in kernel/sched/sched.h not include/linux/sched.h Peter, is there a reason that task_nice() is not a static inline in sched.h and have these macros there too? They only reference fields in task_struct that are already defined there. I don't see why they need to be private to kernel/sched. -- Steve > > Thanks, > > -- Steve > > > max_data->policy = tsk->policy; > > max_data->rt_priority = tsk->rt_priority; > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tracing: Use task_nice() in function __update_max_tr() to get the nice value of task.
On Wed, 22 Jan 2014 17:41:45 -0500 Dongsheng Yang wrote: > There is already a function named task_nice in sched.h to get the nice value > of task_struct. We can use it in __update_max_tr() rather than calculate it > manually. > > Signed-off-by: Dongsheng Yang > --- > kernel/trace/trace.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index 9d20cd9..ec149b4 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -970,7 +970,7 @@ __update_max_tr(struct trace_array *tr, struct > task_struct *tsk, int cpu) > else > max_data->uid = task_uid(tsk); > > - max_data->nice = tsk->static_prio - 20 - MAX_RT_PRIO; > + max_data->nice = task_nice(tsk); Except that's a function call in a critical path. Switch it to TASK_NICE(), and I'll take the patch. Thanks, -- Steve > max_data->policy = tsk->policy; > max_data->rt_priority = tsk->rt_priority; > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Internal error: Oops: 17 [#1] ARM
On Wed, Jan 22, 2014 at 07:28:55PM -0800, John Tobias wrote: >Hi Liming, > >Yes, I am using 4.8.1. I switched back to 4.7.3 and will test it again >if I can re-produce it. Hi, Or you can use the latest linaro 4.8.x toolchain, which has been applied that patch: http://releases.linaro.org/13.12/components/toolchain/binaries/ Please select this one to try: gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux.tar.bz2 Liming Wang > >Regards, > >john > >On Wed, Jan 22, 2014 at 7:01 PM, walimis wrote: >> On Wed, Jan 22, 2014 at 08:23:36AM -0800, John Tobias wrote: >>>Hello all, >>> >>>I am using 3.13-rc1 kernel on iMX6SL processor. My filesystem is in >>>eMMC running SDR50. >>>Is anyone here encountered these problem and if there's any existing >>>patch that I can get?. >> hi, >> >> Do you use gcc 4.8.1? If so, maybe you should look at following link >> to see whether it's a similar issue. >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 >> >> Liming Wang >> >>> >>>Regards, >>> >>>john >>> >>>[ 1552.394899] Unable to handle kernel NULL pointer dereference at >>>virtual address 0037 >>>[ 1552.403034] pgd = beef4000 >>>[ 1552.405855] [0037] *pgd=bef60831, *pte=, *ppte= >>>[ 1552.412245] Internal error: Oops: 17 [#1] ARM >>>[ 1552.416627] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(O) >>>[ 1552.422249] CPU: 0 PID: 232 Comm: commsd Tainted: G O >>>3.13.0-rc1 #7 >>>[ 1552.429409] task: bfbc7500 ti: bec96000 task.ti: bec96000 >>>[ 1552.434844] PC is at lookup_fast+0x5c/0x318 >>>[ 1552.439067] LR is at mark_held_locks+0x78/0x13c >>>[ 1552.443622] pc : [<80101184>]lr : [<80056e48>]psr: a00f0013 >>>[ 1552.443622] sp : bec97d88 ip : 00666e6f fp : bec97ddc >>>[ 1552.455124] r10: r9 : bec97e08 r8 : 80102d94 >>>[ 1552.460370] r7 : bec97e60 r6 : bf133ac8 r5 : bec97e60 r4 : bec97e00 >>>[ 1552.466918] r3 : bee4f01d r2 : r1 : r0 : >>>[ 1552.473471] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment >>>user >>>[ 1552.480629] Control: 10c53c7d Table: beef4059 DAC: 0015 >>>[ 1552.486397] Process commsd (pid: 232, stack limit = 0xbec96238) >>>[ 1552.492341] Stack: (0xbec97d88 to 0xbec98000) >>>[ 1552.496728] 7d80: 80102b94 80057108 bfb95310 >>>bf133ac8 bf15f4e8 bfb95310 >>>[ 1552.504936] 7da0: c08bb14d bee4f015 0008 bfbc7500 >>>bec97e08 0041 >>>[ 1552.513142] 7dc0: bec97e60 bec96020 bec96000 bec97e3c >>>bec97de0 80102d94 80101134 >>>[ 1552.521347] 7de0: bec97df8 800d982c bec96018 0010 >>>bec97e00 bec97e08 >>>[ 1552.529553] 7e00: 8026e25c 800d97e8 bee4f000 0ff0 80d4e3a4 >>>0001 bee4f000 bec97e60 >>>[ 1552.537758] 7e20: ff9c ff9c bec96000 bec97e5c >>>bec97e40 801033bc 80102c70 >>>[ 1552.545964] 7e40: bee4f000 0001 bec97e60 bec97f00 bec97ee4 >>>bec97e60 80105dc0 80103398 >>>[ 1552.554170] 7e60: bfb95310 bf133ac8 c08bb14d 000b bee4f015 >>>8005992c bfb95310 bf133398 >>>[ 1552.562375] 7e80: bf15f4e8 0041 0002 008a >>> 600f0013 bec96000 >>>[ 1552.570581] 7ea0: ffea bf8c1840 807b4430 80115444 801156e4 >>>8011563c 0008 >>>[ 1552.578786] 7ec0: bec97f04 733fe4e0 0001 ff9c 757e3810 >>>bec97f40 bec97efc bec97ee8 >>>[ 1552.586991] 7ee0: 80105e0c 80105d68 bc950fe0 bec97f2c >>>bec97f00 800faf64 80105df4 >>>[ 1552.595196] 7f00: 801156e4 80115420 bec97f54 733fe4e0 733ff8f0 >>>733fe61c 00c3 8000f504 >>>[ 1552.603402] 7f20: bec97f3c bec97f30 800fafe0 800faf1c bec97fa4 >>>bec97f40 800fb71c 800fafc4 >>>[ 1552.611608] 7f40: 8000f310 bfbc7500 733fe550 8000f458 733fe61c >>>00c3 bec97f84 bec97f68 >>>[ 1552.619813] 7f60: 80056f28 800a0270 733fe550 733ff8f0 733fe61c >>>00c3 bec97f94 bec97f88 >>>[ 1552.628019] 7f80: 80057110 80056f18 bec97f98 8000f458 >>>733fe550 bec97fa8 >>>[ 1552.636226] 7fa0: 8000f280 800fb704 733fe550 733ff8f0 757e3810 >>>733fe4e0 733fe550 0003 >>>[ 1552.644431] 7fc0: 733fe550 733ff8f0 733fe61c 00c3 >>>0002 733fe92c 0200 >>>[ 1552.652636] 7fe0: 00c3 733fe4d8 7579b7e5 7572e276 200f0030 >>>757e3810 bfffd821 bfffdc21 >>>[ 1552.660828] Backtrace: >>>[ 1552.663343] [<80101128>] (lookup_fast+0x0/0x318) from [<80102d94>] >>>(path_lookupat+0x130/0x728) >>>[ 1552.671994] [<80102c64>] (path_lookupat+0x0/0x728) from >>>[<801033bc>] (filename_lookup.isra.40+0x30/0x70) >>>[ 1552.681515] [<8010338c>] (filename_lookup.isra.40+0x0/0x70) from >>>[<80105dc0>] (user_path_at_empty+0x64/0x8c) >>>[ 1552.691361] r7:bec97f00 r6:bec97e60 r5:0001 r4:bee4f000 >>>[ 1552.697163] [<80105d5c>] (user_path_at_empty+0x0/0x8c) from >>>[<80105e0c>] (user_path_at+0x24/0x2c) >>>[ 1552.706053] r8:bec97f40 r7:757e3810 r6:ff9c r5:0001 r4:733fe4e0 >>>[ 1552.712927] [<80105de8>] (user_path_at+0x0/0x2c) from [<800faf64>] >>>(vfs_fstatat+0x54/0xa8) >>>[ 1552.721232] [<800faf10>] (vfs_fstatat+0x0/0xa8) from [<800fafe0>] >>>(vfs_stat+0x
[PATCH v5] ACPI: Fix acpi_evaluate_object() return value check
Since acpi_evaluate_object() returns acpi_status and not plain int,
ACPI_FAILURE() should be used for checking its return value. Also
add some detailed debug info when acpi_evaluate_object() failed.
Reviewed-by: Jani Nikula
Acked-by: Bjorn Helgaas
Signed-off-by: Yijing Wang
---
v4->v5: Add some detailed debug info for acpi_evaluate_object()
failure suggested by Bjorn.
v3->v4: Fix spell error, add Jani Nikula reviewed-by.
v2->v3: Fix compile error pointed out by Hanjun.
v1->v2: Add CC to related subsystem MAINTAINERS
---
drivers/gpu/drm/i915/intel_acpi.c | 33 ---
drivers/gpu/drm/nouveau/core/subdev/mxm/base.c | 13 ++---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 25 +++---
drivers/pci/pci-label.c| 10 +--
4 files changed, 54 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_acpi.c
b/drivers/gpu/drm/i915/intel_acpi.c
index dfff090..e7b526b 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -31,11 +31,13 @@ static const u8 intel_dsm_guid[] = {
static int intel_dsm(acpi_handle handle, int func)
{
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *obj;
u32 result;
- int ret = 0;
+ acpi_status status;
+ int ret;
input.count = 4;
input.pointer = params;
@@ -50,10 +52,14 @@ static int intel_dsm(acpi_handle handle, int func)
params[3].package.count = 0;
params[3].package.elements = NULL;
- ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
- if (ret) {
- DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
- return ret;
+ status = acpi_evaluate_object(handle, "_DSM", &input, &output);
+ if (ACPI_FAILURE(status)) {
+ acpi_get_name(handle, ACPI_FULL_PATHNAME, &string);
+ DRM_DEBUG_DRIVER(
+ "failed to evaluate _DSM for %s, exit status %u\n",
+ (char *)string.pointer, (unsigned int)status);
+ kfree(string.pointer);
+ return -EINVAL;
}
obj = (union acpi_object *)output.pointer;
@@ -138,10 +144,12 @@ static char *intel_dsm_mux_type(u8 type)
static void intel_dsm_platform_mux_info(void)
{
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *pkg;
- int i, ret;
+ acpi_status status;
+ int i;
input.count = 4;
input.pointer = params;
@@ -156,10 +164,15 @@ static void intel_dsm_platform_mux_info(void)
params[3].package.count = 0;
params[3].package.elements = NULL;
- ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", &input,
- &output);
- if (ret) {
- DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
+ acpi_status = acpi_evaluate_object(intel_dsm_priv.dhandle,
+ "_DSM", &input, &output);
+ if (ACPI_FAILURE(status)) {
+ acpi_get_name(intel_dsm_priv.dhandle,
+ ACPI_FULL_PATHNAME, &string);
+ DRM_DEBUG_DRIVER(
+ "failed to evaluate _DSM for %s, exit status %u\n",
+ (char *)string.pointer, (unsigned int)status);
+ kfree(string.pointer);
goto out;
}
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
index 1291204..c30ee88 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
@@ -112,17 +112,22 @@ mxm_shadow_dsm(struct nouveau_mxm *mxm, u8 version)
};
struct acpi_object_list list = { ARRAY_SIZE(args), args };
struct acpi_buffer retn = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer string = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
acpi_handle handle;
- int ret;
+ acpi_status status;
handle = ACPI_HANDLE(&device->pdev->dev);
if (!handle)
return false;
- ret = acpi_evaluate_object(handle, "_DSM", &list, &retn);
- if (ret) {
- nv_debug(mxm, "DSM MXMS failed: %d\n", ret);
+ status = acpi_evaluate_object(handle, "_DSM", &list, &retn);
+ if (ACPI_FAILURE(status)) {
+ acpi_get_name(handle, ACPI_FULL_PATHNAME, &string);
+ nv_debug(mxm, "DSM MXMS failed for %s: exit status %u\n",
+ (char *)string.pointer,
+ (unsigned
Re: [PATCH V5 6/8] time/cpuidle: Support in tick broadcast framework in the absence of external clock device
Hi Thomas,
Thank you very much for the review.
On 01/22/2014 06:57 PM, Thomas Gleixner wrote:
> On Wed, 15 Jan 2014, Preeti U Murthy wrote:
>> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
>> index 086ad60..d61404e 100644
>> --- a/kernel/time/clockevents.c
>> +++ b/kernel/time/clockevents.c
>> @@ -524,12 +524,13 @@ void clockevents_resume(void)
>> #ifdef CONFIG_GENERIC_CLOCKEVENTS
>> /**
>> * clockevents_notify - notification about relevant events
>> + * Returns non zero on error.
>> */
>> -void clockevents_notify(unsigned long reason, void *arg)
>> +int clockevents_notify(unsigned long reason, void *arg)
>> {
>
> The interface change of clockevents_notify wants to be a separate
> patch.
>
>> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
>> index 9532690..1c23912 100644
>> --- a/kernel/time/tick-broadcast.c
>> +++ b/kernel/time/tick-broadcast.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "tick-internal.h"
>>
>> @@ -35,6 +36,15 @@ static cpumask_var_t tmpmask;
>> static DEFINE_RAW_SPINLOCK(tick_broadcast_lock);
>> static int tick_broadcast_force;
>>
>> +/*
>> + * Helper variables for handling broadcast in the absence of a
>> + * tick_broadcast_device.
>> + * */
>> +static struct hrtimer *bc_hrtimer;
>> +static int bc_cpu = -1;
>> +static ktime_t bc_next_wakeup;
>
> Why do you need another variable to store the expiry time? The
> broadcast code already knows it and the hrtimer expiry value gives you
> the same information for free.
The reason was functions like tick_handle_oneshot_broadcast() and
tick_broadcast_switch_to_oneshot() were using the
tick_broadcast_device.evtdev->next_event to set/get the next wakeups.
But since this patchset introduced an explicit hrtimer for archs which
did not have such a device, I wanted these functions to use a generic
parameter to set/get the next wakeups without having to know about the
existence of this hrtimer, if at all. And program the hrtimer/tick
broadcast device whichever was present only when the next event was to
be set. But with your below concept patch, we will not be required to do
this.
>
>> +static int hrtimer_initialized = 0;
>
> What's the point of this hrtimer_initialized dance? Why not simply
> making the hrtimer static and avoid that all together. Also adding the
> initialization into tick_broadcast_oneshot_available() is
> braindamaged. Why not adding this to tick_broadcast_init() which is
> the proper place to do?
Right I agree, this hrtimer initialization should have been in
tick_broadcast_init() and a simple static declaration would have done
the job.
>
> Aside of that you are making this hrtimer mode unconditional, which
> might break existing systems which are not aware of the hrtimer
> implications.
>
> What you really want is a pseudo clock event device which has the
> proper functions for handling the timer and you can register it from
> your architecture code. The broadcast core code needs a few tweaks to
> avoid the shutdown of the cpu local clock event device, but aside of
> that the whole thing just falls into place. So architectures can use
> this if they want and are sure that their low level idle code knows
> about the deep idle preventing return value of
> clockevents_notify(). Once that works you can register the hrtimer
> based broadcast device and a real hardware broadcast device with a
> higher rating. It just works.
I now completely see your point. This will surely break on archs which
are not using the return value of the BROADCAST_ENTER notification.
I am not even giving them a choice about using the hrtimer mode of
broadcast framework and am expecting them to take action for the failed
return of BROADCAST_ENTER. I missed that critical point. I went through
the below patch and am able to see how you are solving this problem.
>
> Find an incomplete and nonfunctional concept patch below. It should be
> simple to make it work for real.
Thank you very much for the valuable review. The below patch makes your
points very clear. Let me try this out.
Regards
Preeti U Murthy
>
> Thanks,
>
> tglx
>
> Index: linux-2.6/include/linux/clockchips.h
> ===
> --- linux-2.6.orig/include/linux/clockchips.h
> +++ linux-2.6/include/linux/clockchips.h
> @@ -62,6 +62,11 @@ enum clock_event_mode {
> #define CLOCK_EVT_FEAT_DYNIRQ0x20
> #define CLOCK_EVT_FEAT_PERCPU0x40
>
> +/*
> + * Clockevent device is based on a hrtimer for broadcast
> + */
> +#define CLOCK_EVT_FEAT_HRTIMER 0x80
> +
> /**
> * struct clock_event_device - clock event device descriptor
> * @event_handler: Assigned by the framework to be called by the low
> @@ -83,6 +88,7 @@ enum clock_event_mode {
> * @name:ptr to clock event name
> * @rating: variable to rate clock event devices
> * @irq:
Re: Internal error: Oops: 17 [#1] ARM
Hi Liming, Yes, I am using 4.8.1. I switched back to 4.7.3 and will test it again if I can re-produce it. Regards, john On Wed, Jan 22, 2014 at 7:01 PM, walimis wrote: > On Wed, Jan 22, 2014 at 08:23:36AM -0800, John Tobias wrote: >>Hello all, >> >>I am using 3.13-rc1 kernel on iMX6SL processor. My filesystem is in >>eMMC running SDR50. >>Is anyone here encountered these problem and if there's any existing >>patch that I can get?. > hi, > > Do you use gcc 4.8.1? If so, maybe you should look at following link > to see whether it's a similar issue. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 > > Liming Wang > >> >>Regards, >> >>john >> >>[ 1552.394899] Unable to handle kernel NULL pointer dereference at >>virtual address 0037 >>[ 1552.403034] pgd = beef4000 >>[ 1552.405855] [0037] *pgd=bef60831, *pte=, *ppte= >>[ 1552.412245] Internal error: Oops: 17 [#1] ARM >>[ 1552.416627] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(O) >>[ 1552.422249] CPU: 0 PID: 232 Comm: commsd Tainted: G O 3.13.0-rc1 >>#7 >>[ 1552.429409] task: bfbc7500 ti: bec96000 task.ti: bec96000 >>[ 1552.434844] PC is at lookup_fast+0x5c/0x318 >>[ 1552.439067] LR is at mark_held_locks+0x78/0x13c >>[ 1552.443622] pc : [<80101184>]lr : [<80056e48>]psr: a00f0013 >>[ 1552.443622] sp : bec97d88 ip : 00666e6f fp : bec97ddc >>[ 1552.455124] r10: r9 : bec97e08 r8 : 80102d94 >>[ 1552.460370] r7 : bec97e60 r6 : bf133ac8 r5 : bec97e60 r4 : bec97e00 >>[ 1552.466918] r3 : bee4f01d r2 : r1 : r0 : >>[ 1552.473471] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment >>user >>[ 1552.480629] Control: 10c53c7d Table: beef4059 DAC: 0015 >>[ 1552.486397] Process commsd (pid: 232, stack limit = 0xbec96238) >>[ 1552.492341] Stack: (0xbec97d88 to 0xbec98000) >>[ 1552.496728] 7d80: 80102b94 80057108 bfb95310 >>bf133ac8 bf15f4e8 bfb95310 >>[ 1552.504936] 7da0: c08bb14d bee4f015 0008 bfbc7500 >>bec97e08 0041 >>[ 1552.513142] 7dc0: bec97e60 bec96020 bec96000 bec97e3c >>bec97de0 80102d94 80101134 >>[ 1552.521347] 7de0: bec97df8 800d982c bec96018 0010 >>bec97e00 bec97e08 >>[ 1552.529553] 7e00: 8026e25c 800d97e8 bee4f000 0ff0 80d4e3a4 >>0001 bee4f000 bec97e60 >>[ 1552.537758] 7e20: ff9c ff9c bec96000 bec97e5c >>bec97e40 801033bc 80102c70 >>[ 1552.545964] 7e40: bee4f000 0001 bec97e60 bec97f00 bec97ee4 >>bec97e60 80105dc0 80103398 >>[ 1552.554170] 7e60: bfb95310 bf133ac8 c08bb14d 000b bee4f015 >>8005992c bfb95310 bf133398 >>[ 1552.562375] 7e80: bf15f4e8 0041 0002 008a >> 600f0013 bec96000 >>[ 1552.570581] 7ea0: ffea bf8c1840 807b4430 80115444 801156e4 >>8011563c 0008 >>[ 1552.578786] 7ec0: bec97f04 733fe4e0 0001 ff9c 757e3810 >>bec97f40 bec97efc bec97ee8 >>[ 1552.586991] 7ee0: 80105e0c 80105d68 bc950fe0 bec97f2c >>bec97f00 800faf64 80105df4 >>[ 1552.595196] 7f00: 801156e4 80115420 bec97f54 733fe4e0 733ff8f0 >>733fe61c 00c3 8000f504 >>[ 1552.603402] 7f20: bec97f3c bec97f30 800fafe0 800faf1c bec97fa4 >>bec97f40 800fb71c 800fafc4 >>[ 1552.611608] 7f40: 8000f310 bfbc7500 733fe550 8000f458 733fe61c >>00c3 bec97f84 bec97f68 >>[ 1552.619813] 7f60: 80056f28 800a0270 733fe550 733ff8f0 733fe61c >>00c3 bec97f94 bec97f88 >>[ 1552.628019] 7f80: 80057110 80056f18 bec97f98 8000f458 >>733fe550 bec97fa8 >>[ 1552.636226] 7fa0: 8000f280 800fb704 733fe550 733ff8f0 757e3810 >>733fe4e0 733fe550 0003 >>[ 1552.644431] 7fc0: 733fe550 733ff8f0 733fe61c 00c3 >>0002 733fe92c 0200 >>[ 1552.652636] 7fe0: 00c3 733fe4d8 7579b7e5 7572e276 200f0030 >>757e3810 bfffd821 bfffdc21 >>[ 1552.660828] Backtrace: >>[ 1552.663343] [<80101128>] (lookup_fast+0x0/0x318) from [<80102d94>] >>(path_lookupat+0x130/0x728) >>[ 1552.671994] [<80102c64>] (path_lookupat+0x0/0x728) from >>[<801033bc>] (filename_lookup.isra.40+0x30/0x70) >>[ 1552.681515] [<8010338c>] (filename_lookup.isra.40+0x0/0x70) from >>[<80105dc0>] (user_path_at_empty+0x64/0x8c) >>[ 1552.691361] r7:bec97f00 r6:bec97e60 r5:0001 r4:bee4f000 >>[ 1552.697163] [<80105d5c>] (user_path_at_empty+0x0/0x8c) from >>[<80105e0c>] (user_path_at+0x24/0x2c) >>[ 1552.706053] r8:bec97f40 r7:757e3810 r6:ff9c r5:0001 r4:733fe4e0 >>[ 1552.712927] [<80105de8>] (user_path_at+0x0/0x2c) from [<800faf64>] >>(vfs_fstatat+0x54/0xa8) >>[ 1552.721232] [<800faf10>] (vfs_fstatat+0x0/0xa8) from [<800fafe0>] >>(vfs_stat+0x28/0x2c) >>[ 1552.729167] r8:8000f504 r7:00c3 r6:733fe61c r5:733ff8f0 r4:733fe4e0 >>[ 1552.736031] [<800fafb8>] (vfs_stat+0x0/0x2c) from [<800fb71c>] >>(SyS_stat64+0x24/0x40) >>[ 1552.743902] [<800fb6f8>] (SyS_stat64+0x0/0x40) from [<8000f280>] >>(ret_fast_syscall+0x0/0x48) >>[ 1552.752359] r4:733fe550 >>[ 1552.754946] Code: eb00352d e350 e50b0038 0a80 (e5903038) >>[ 1552.761270] ---[ end trace 02679086a39365e
Re: Internal error: Oops: 17 [#1] ARM
Hi Fabio, Attached are the two patch files that I applied in the 3.13 released so that the kernel will detect my eMMC in DDR50. (let me correct my previous email, I was mentioning SDR50 but it should be DDR50). eMMC info: clock: 5200 Hz actual clock: 4950 Hz vdd:21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select:0 (don't care) power mode: 2 (on) bus width: 3 (8 bits) timing spec:1 (mmc high-speed) signal voltage: 0 (3.30 V) I reboot my device often and it shows during the reboot. Regards, john On Wed, Jan 22, 2014 at 6:28 PM, Fabio Estevam wrote: > On Wed, Jan 22, 2014 at 9:49 PM, John Tobias wrote: >> Hello all, >> >> Just to confirm that the error I posted previously exist in 3.13 >> released. Just be noted that some patches related to eMMC/sdhci has >> been applied in order to boot the 3.13 on my board. >> Addition to that, I was getting additional errors (please see below): >> - It happened during the reboot. >> >> Cc'ng Dong Aisheng. > > What are the steps to reproduce this? Which SoC are you using? > > Regards, > > Fabio Estevam sdhci-esdhc-imx.patch Description: Binary data sdhci.patch Description: Binary data
Re: [V0 PATCH] xen/pvh: set some cr flags upon vcpu start
On Mon, 20 Jan 2014 10:09:30 -0500 Konrad Rzeszutek Wilk wrote: > On Fri, Jan 17, 2014 at 06:24:55PM -0800, Mukesh Rathor wrote: > > pvh was designed to start with pv flags, but a commit in xen tree > > Thank you for posting this! > > > 51e2cac257ec8b4080d89f0855c498cbbd76a5e5 removed some of the flags > > as > > You need to always include the title of said commit. > > > they are not necessary. As a result, these CR flags must be set in > > the guest. > > I sent out replies to this over the weekend but somehow they are not > showing up. > Well, they finally showed up today... US mail must be slow :)... > > > + > > + if (!cpu) > > + return; > > And what happens if don't have this check? Will be bad if do multiple > cr4 writes? no, but just confuses the reader/debugger of the code IMO :)... > Fyi, this (cr4) should have been a seperate patch. I fixed it up that > way. > > + /* > > +* Unlike PV, for pvh xen does not set: PSE PGE OSFXSR > > OSXMMEXCPT > > +* For BSP, PSE PGE will be set in probe_page_size_mask(), > > for AP > > +* set them here. For all, OSFXSR OSXMMEXCPT will be set > > in fpu_init > > +*/ > > + if (cpu_has_pse) > > + set_in_cr4(X86_CR4_PSE); > > + > > + if (cpu_has_pge) > > + set_in_cr4(X86_CR4_PGE); > > +} > > Seperate patch and since the PGE part is more complicated that just > setting the CR4 - you also have to tweak this: > > 1512 /* Prevent unwanted bits from being set in PTEs. > */ 1513 __supported_pte_mask &= > ~_PAGE_GLOBAL; > > I think it should be done once we have actually confirmed that you can > do 2MB pages within the guest. (might need some more tweaking?) Umm... well, the above is just setting the PSE and PGE in the APs, the BSP is already doing that in probe_page_size_mask, and setting __supported_pte_mask which needs to be set just once. So, because it's being set in the BSP, it's already broken/untested if we add expose of PGE from xen to a linux PVH guest... IOW, leaving above is no more harm, or we should 'if (pvh)' the code in probe_page_size_mask() for PSE, and wait till we can test it... thanks Mukesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kvm virtio ethernet ring on guest side over high throughput (packet per second)
On 01/23/2014 05:32 AM, Alejandro Comisario wrote: > Thank you so much Stefan for the help and cc'ing Michael & Jason. > Like you advised yesterday on IRC, today we are making some tests with > the application setting TCP_NODELAY in the socket options. > > So we will try that and get back to you with further information. > In the mean time, maybe showing what options the vms are using while running ! > > # > -- > /usr/bin/kvm -S -M pc-1.0 -cpu > core2duo,+lahf_lm,+rdtscp,+pdpe1gb,+aes,+popcnt,+x2apic,+sse4.2,+sse4.1,+dca,+xtpr,+cx16,+tm2,+est,+vmx,+ds_cpl,+pbe,+tm,+ht,+ss,+acpi,+ds > -enable-kvm -m 32768 -smp 8,sockets=1,cores=6,threads=2 -name > instance-0254 -uuid d25b1b20-409e-4d7f-bd92-2ef4073c7c2b > -nodefconfig -nodefaults -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-0254.monitor,server,nowait > -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc > -no-shutdown -kernel /var/lib/nova/instances/instance-0254/kernel > -initrd /var/lib/nova/instances/instance-0254/ramdisk -append > root=/dev/vda console=ttyS0 -drive > file=/var/lib/nova/instances/instance-0254/disk,if=none,id=drive-virtio-disk0,format=qcow2,cache=writethrough > -device > virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 > -netdev tap,fd=19,id=hostnet0 -device Better enable vhost as Stefan suggested. It may help a lot here. > virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:27:d4:6d,bus=pci.0,addr=0x3 > -chardev > file,id=charserial0,path=/var/lib/nova/instances/instance-0254/console.log > -device isa-serial,chardev=charserial0,id=serial0 -chardev > pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 > -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:4 -k en-us -vga cirrus > -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 > # > -- > > best regards > > > Alejandro Comisario > #melicloud CloudBuilders > Arias 3751, Piso 7 (C1430CRG) > Ciudad de Buenos Aires - Argentina > Cel: +549(11) 15-3770-1857 > Tel : +54(11) 4640-8443 > > > On Wed, Jan 22, 2014 at 12:22 PM, Stefan Hajnoczi wrote: >> On Tue, Jan 21, 2014 at 04:06:05PM -0200, Alejandro Comisario wrote: >> >> CCed Michael Tsirkin and Jason Wang who work on KVM networking. >> >>> Hi guys, we had in the past when using physical servers, several >>> throughput issues regarding the throughput of our APIS, in our case we >>> measure this with packets per seconds, since we dont have that much >>> bandwidth (Mb/s) since our apis respond lots of packets very small >>> ones (maximum response of 3.5k and avg response of 1.5k), when we >>> where using this physical servers, when we reach throughput capacity >>> (due to clients tiemouts) we touched the ethernet ring configuration >>> and we made the problem dissapear. >>> >>> Today with kvm and over 10k virtual instances, when we want to >>> increase the throughput of KVM instances, we bumped with the fact that >>> when using virtio on guests, we have a max configuration of the ring >>> of 256 TX/RX, and from the host side the atached vnet has a txqueuelen >>> of 500. >>> >>> What i want to know is, how can i tune the guest to support more >>> packets per seccond if i know that's my bottleneck? >> I suggest investigating performance in a systematic way. Set up a >> benchmark that saturates the network. Post the details of the benchmark >> and the results that you are seeing. >> >> Then, we can discuss how to investigate the root cause of the bottleneck. >> >>> * does virtio exposes more packets to configure in the virtual ethernet's >>> ring ? >> No, ring size is hardcoded in QEMU (on the host). >> >>> * does the use of vhost_net helps me with increasing packets per >>> second and not only bandwidth? >> vhost_net is generally the most performant network option. >> >>> does anyone has to struggle with this before and knows where i can look >>> into ? >>> there's LOOOTS of information about networking performance >>> tuning of kvm, but nothing related to increase throughput in pps >>> capacity. >>> >>> This is a couple of configurations that we are having right now on the >>> compute nodes: >>> >>> * 2x1Gb bonded interfaces (want to know the more than 20 models we are >>> using, just ask for it) >>> * Multi queue interfaces, pined via irq to different cores >>> * Linux bridges, no VLAN, no open-vswitch >>> * ubuntu 12.04 kernel 3.2.0-[40-48] > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubsc
Re: mm: BUG: Bad rss-counter state
On 01/22/2014 09:21 PM, Dave Jones wrote: On Wed, Jan 22, 2014 at 09:16:03PM -0500, Sasha Levin wrote: > On 01/22/2014 08:52 PM, Dave Jones wrote: > > Sasha, is this the current git tree version of Trinity ? > > (I'm wondering if yesterdays munmap changes might be tickling this bug). > > Ah yes, my tree has the munmap patch from yesterday, which would explain why we > started seeing this issue just now. So that change is basically allowing trinity to munmap just part of a prior mmap. So it may do things like.. mmap |--| munmap |XXX---| munmap |--XXX-| ie, it might try unmapping some pages more than once, and may even overlap prior munmaps. until yesterdays change, it would only munmap the entire mmap. There's no easy way to tell exactly what happened without a trinity log of course. I've attached the trinity log of the child that triggered the bug. Odd thing is that I don't see any munmaps in it. Thanks, Sasha [child234:9994] [0] [32BIT] munlock(addr=0x7f724f784000, len=0x40) = -1 (Cannot allocate memory) [child234:9994] [1] remap_file_pages(start=0x7f724e984000, size=0x406f79, prot=0, pgoff=6, flags=0x1) = 0 [child234:9994] [2] vmsplice(fd=682, iov=0x318d710, nr_segs=404, flags=2) = 0x5000 [child234:9994] [3] mbind(start=0x7f724f384000, len=0x40, mode=1, nmask=0, maxnode=0x8000, flags=0) = 0 [child234:9994] [4] mmap(addr=0, len=0x20, prot=7[PROT_READ|PROT_WRITE|PROT_EXEC], flags=0x43842, fd=682, off=0) = -1 (Invalid argument) [child234:9994] [5] mprotect(start=0x7f7250384000, len=0x20, prot=0) = 0 [child234:9994] [6] mprotect(start=0x7f7250886000, len=8192, prot=0x205) = -1 (Invalid argument) [child234:9994] [7] munlock(addr=0x7f7250584000, len=0x10) = 0 [child234:9994] [8] [32BIT] mlock(addr=0x7f7250684000, len=0x10) = -1 (Cannot allocate memory) [child234:9994] [9] move_pages(pid=0, nr_pages=236, pages=0x3015ed0, nodes=0x3111010, status=0x31909d0, flags=4) = 0 [child234:9994] [10] mlock(addr=0x7f7250384000, len=0x20) = -1 (Cannot allocate memory) [child234:9994] [11] remap_file_pages(start=0x7f724f784000, size=0x3bbfbd, prot=0, pgoff=19, flags=0) = 0 [child234:9994] [12] msync(start=0x7f724d584000, len=0xa0, flags=3) = 0 [child234:9994] [13] mlock(addr=0x7f7250684000, len=0x10) = 0 [child234:9994] [14] madvise(start=0x7f7250384000, len_in=0x20, advice=0) = 0 [child234:9994] [15] mlock(addr=0x7f7250888000, len=8192) = 0 [child234:9994] [16] mbind(start=0x7f7250584000, len=0x10, mode=0, nmask=0, maxnode=0x8000, flags=0x4000) = -1 (Invalid argument) [child234:9994] [17] move_pages(pid=9896, nr_pages=124, pages=0x3015ed0, nodes=0x3190d90, status=0x3109500, flags=4) = -1 (Invalid argument) [child234:9994] [18] mprotect(start=0x7f724df84000, len=0xa0, prot=8) = 0 [child234:9994] [19] move_pages(pid=0, nr_pages=221, pages=0x3015ed0, nodes=0x3109700, status=0x3109a80, flags=6) = 0 [child234:9994] [20] [32BIT] madvise(start=0x7f7250184000, len_in=0x20, advice=14) = -1 (Cannot allocate memory) [child234:9994] [21] move_pages(pid=0, nr_pages=337, pages=0x3015ed0, nodes=0x318f790, status=0x318fce0, flags=4) = 0 [child234:9994] [22] move_pages(pid=9981, nr_pages=115, pages=0x3015ed0, nodes=0x3109e00, status=0x9db1a0, flags=4) = 0 [child234:9994] [23] migrate_pages(pid=0, maxnode=0x680016c3, old_nodes=0x6ba000[page_0xff], new_nodes=0x8100) = -1 (Invalid argument) [child234:9994] [24] msync(start=0x7f7250384000, len=0x20, flags=1) = 0 [child234:9994] [25] msync(start=0x7f724fb84000, len=0x40, flags=6) = 0 [child234:9994] [26] mincore(start=0, len=0, vec=0x8100) = -1 (Bad address) [child234:9994] [27] remap_file_pages(start=0x7f7250184000, size=0x1597ab, prot=0, pgoff=336, flags=0) = 0 [child234:9994] [28] move_pages(pid=0, nr_pages=99, pages=0x3015ed0, nodes=0x3190230, status=0x9db380, flags=0) = 0 [child234:9994] [29] mincore(start=0x7f724df84000, len=0x31978b, vec=0x7f724df84001) = -1 (Bad address) [child234:9994] [30] move_pages(pid=9962, nr_pages=83, pages=0x3015ed0, nodes=0x31113d0, status=0x9db520, flags=6) = -1 (Invalid argument) [child234:9994] [31] [32BIT] madvise(start=0x7f7250384000, len_in=0x20, advice=9) = -1 (Cannot allocate memory) [child234:9994] [32] msync(start=0x7f7250886000, len=8192, flags=6) = 0 [child234:9994] [33] migrate_pages(pid=0, maxnode=0x929292929292, old_nodes=1, new_nodes=0x6c[page_allocs]) = -1 (Invalid argument) [child234:9994] [34] mlock(addr=0x7f7250888000, len=8192) = 0 [child234:9994] [35] mbind(start=0x7f724fb84000, len=0x40, mode=3, nmask=0x6c[page_allocs], maxnode=0x8000, flags=0) = -1 (Invalid argument) [child234:9994] [36] vmsplice(fd=681, iov=0x31903d0, nr_segs=68, flags=1) = 4096 [child234:9994] [37] mbind(start=0x7f7250584000, len=0x10, mode=3, nmask=0x3016ee0, maxnode=0x8000, flags=0x8000) = -1 (Invalid argument) [child234:9994] [38] mmap(addr=0, len=0x4000, prot=6[PROT_WRITE|PROT_EXEC
Re: kvm virtio ethernet ring on guest side over high throughput (packet per second)
On 01/22/2014 11:22 PM, Stefan Hajnoczi wrote: > On Tue, Jan 21, 2014 at 04:06:05PM -0200, Alejandro Comisario wrote: > > CCed Michael Tsirkin and Jason Wang who work on KVM networking. > >> Hi guys, we had in the past when using physical servers, several >> throughput issues regarding the throughput of our APIS, in our case we >> measure this with packets per seconds, since we dont have that much >> bandwidth (Mb/s) since our apis respond lots of packets very small >> ones (maximum response of 3.5k and avg response of 1.5k), when we >> where using this physical servers, when we reach throughput capacity >> (due to clients tiemouts) we touched the ethernet ring configuration >> and we made the problem dissapear. >> >> Today with kvm and over 10k virtual instances, when we want to >> increase the throughput of KVM instances, we bumped with the fact that >> when using virtio on guests, we have a max configuration of the ring >> of 256 TX/RX, and from the host side the atached vnet has a txqueuelen >> of 500. >> >> What i want to know is, how can i tune the guest to support more >> packets per seccond if i know that's my bottleneck? > I suggest investigating performance in a systematic way. Set up a > benchmark that saturates the network. Post the details of the benchmark > and the results that you are seeing. > > Then, we can discuss how to investigate the root cause of the bottleneck. > >> * does virtio exposes more packets to configure in the virtual ethernet's >> ring ? > No, ring size is hardcoded in QEMU (on the host). Do it make sense to let user can configure it through something at least like qemu command line? > >> * does the use of vhost_net helps me with increasing packets per >> second and not only bandwidth? > vhost_net is generally the most performant network option. > >> does anyone has to struggle with this before and knows where i can look into >> ? >> there's LOOOTS of information about networking performance >> tuning of kvm, but nothing related to increase throughput in pps >> capacity. >> >> This is a couple of configurations that we are having right now on the >> compute nodes: >> >> * 2x1Gb bonded interfaces (want to know the more than 20 models we are >> using, just ask for it) >> * Multi queue interfaces, pined via irq to different cores Maybe you can have a try with multiqueue virtio-net with vhost. It can let guest to use more than one tx/rx virtqueue pairs to do the network processing. >> * Linux bridges, no VLAN, no open-vswitch >> * ubuntu 12.04 kernel 3.2.0-[40-48] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zswap: Check all pool pages instead of one pool pages
Hello Cai,
On Thu, Jan 23, 2014 at 09:38:41AM +0800, Cai Liu wrote:
> Hello Dan
>
> 2014/1/22 Dan Streetman :
> > On Wed, Jan 22, 2014 at 7:16 AM, Cai Liu wrote:
> >> Hello Minchan
> >>
> >>
> >> 2014/1/22 Minchan Kim
> >>>
> >>> Hello Cai,
> >>>
> >>> On Tue, Jan 21, 2014 at 09:52:25PM +0800, Cai Liu wrote:
> >>> > Hello Minchan
> >>> >
> >>> > 2014/1/21 Minchan Kim :
> >>> > > Hello,
> >>> > >
> >>> > > On Tue, Jan 21, 2014 at 02:35:07PM +0800, Cai Liu wrote:
> >>> > >> 2014/1/21 Minchan Kim :
> >>> > >> > Please check your MUA and don't break thread.
> >>> > >> >
> >>> > >> > On Tue, Jan 21, 2014 at 11:07:42AM +0800, Cai Liu wrote:
> >>> > >> >> Thanks for your review.
> >>> > >> >>
> >>> > >> >> 2014/1/21 Minchan Kim :
> >>> > >> >> > Hello Cai,
> >>> > >> >> >
> >>> > >> >> > On Mon, Jan 20, 2014 at 03:50:18PM +0800, Cai Liu wrote:
> >>> > >> >> >> zswap can support multiple swapfiles. So we need to check
> >>> > >> >> >> all zbud pool pages in zswap.
> >>> > >> >> >>
> >>> > >> >> >> Version 2:
> >>> > >> >> >> * add *total_zbud_pages* in zbud to record all the pages in
> >>> > >> >> >> pools
> >>> > >> >> >> * move the updating of pool pages statistics to
> >>> > >> >> >> alloc_zbud_page/free_zbud_page to hide the details
> >>> > >> >> >>
> >>> > >> >> >> Signed-off-by: Cai Liu
> >>> > >> >> >> ---
> >>> > >> >> >> include/linux/zbud.h |2 +-
> >>> > >> >> >> mm/zbud.c| 44
> >>> > >> >> >>
> >>> > >> >> >> mm/zswap.c |4 ++--
> >>> > >> >> >> 3 files changed, 35 insertions(+), 15 deletions(-)
> >>> > >> >> >>
> >>> > >> >> >> diff --git a/include/linux/zbud.h b/include/linux/zbud.h
> >>> > >> >> >> index 2571a5c..1dbc13e 100644
> >>> > >> >> >> --- a/include/linux/zbud.h
> >>> > >> >> >> +++ b/include/linux/zbud.h
> >>> > >> >> >> @@ -17,6 +17,6 @@ void zbud_free(struct zbud_pool *pool,
> >>> > >> >> >> unsigned long handle);
> >>> > >> >> >> int zbud_reclaim_page(struct zbud_pool *pool, unsigned int
> >>> > >> >> >> retries);
> >>> > >> >> >> void *zbud_map(struct zbud_pool *pool, unsigned long handle);
> >>> > >> >> >> void zbud_unmap(struct zbud_pool *pool, unsigned long handle);
> >>> > >> >> >> -u64 zbud_get_pool_size(struct zbud_pool *pool);
> >>> > >> >> >> +u64 zbud_get_pool_size(void);
> >>> > >> >> >>
> >>> > >> >> >> #endif /* _ZBUD_H_ */
> >>> > >> >> >> diff --git a/mm/zbud.c b/mm/zbud.c
> >>> > >> >> >> index 9451361..711aaf4 100644
> >>> > >> >> >> --- a/mm/zbud.c
> >>> > >> >> >> +++ b/mm/zbud.c
> >>> > >> >> >> @@ -52,6 +52,13 @@
> >>> > >> >> >> #include
> >>> > >> >> >> #include
> >>> > >> >> >>
> >>> > >> >> >> +/*
> >>> > >> >> >> +* statistics
> >>> > >> >> >> +**/
> >>> > >> >> >> +
> >>> > >> >> >> +/* zbud pages in all pools */
> >>> > >> >> >> +static u64 total_zbud_pages;
> >>> > >> >> >> +
> >>> > >> >> >> /*
> >>> > >> >> >> * Structures
> >>> > >> >> >> */
> >>> > >> >> >> @@ -142,10 +149,28 @@ static struct zbud_header
> >>> > >> >> >> *init_zbud_page(struct page *page)
> >>> > >> >> >> return zhdr;
> >>> > >> >> >> }
> >>> > >> >> >>
> >>> > >> >> >> +static struct page *alloc_zbud_page(struct zbud_pool *pool,
> >>> > >> >> >> gfp_t gfp)
> >>> > >> >> >> +{
> >>> > >> >> >> + struct page *page;
> >>> > >> >> >> +
> >>> > >> >> >> + page = alloc_page(gfp);
> >>> > >> >> >> +
> >>> > >> >> >> + if (page) {
> >>> > >> >> >> + pool->pages_nr++;
> >>> > >> >> >> + total_zbud_pages++;
> >>> > >> >> >
> >>> > >> >> > Who protect race?
> >>> > >> >>
> >>> > >> >> Yes, here the pool->pages_nr and also the total_zbud_pages are
> >>> > >> >> not protected.
> >>> > >> >> I will re-do it.
> >>> > >> >>
> >>> > >> >> I will change *total_zbud_pages* to atomic type.
> >>> > >> >
> >>> > >> > Wait, it doesn't make sense. Now, you assume zbud allocator would
> >>> > >> > be used
> >>> > >> > for only zswap. It's true until now but we couldn't make sure it
> >>> > >> > in future.
> >>> > >> > If other user start to use zbud allocator, total_zbud_pages would
> >>> > >> > be pointless.
> >>> > >>
> >>> > >> Yes, you are right. ZBUD is a common module. So in this patch
> >>> > >> calculate the
> >>> > >> zswap pool size in zbud is not suitable.
> >>> > >>
> >>> > >> >
> >>> > >> > Another concern is that what's your scenario for above two swap?
> >>> > >> > How often we need to call zbud_get_pool_size?
> >>> > >> > In previous your patch, you reduced the number of call so IIRC,
> >>> > >> > we only called it in zswap_is_full and for debugfs.
> >>> > >>
> >>> > >> zbud_get_pool_size() is called frequently when adding/freeing zswap
> >>> > >> entry happen in zswap . This is why in this patch I added a counter
> >>> > >> in zbud,
> >>> > >> and then in zswap the iteration of zswap_list to calculate the pool
> >>> > >> size will
> >>> > >>
Re: Internal error: Oops: 17 [#1] ARM
On Wed, Jan 22, 2014 at 08:23:36AM -0800, John Tobias wrote: >Hello all, > >I am using 3.13-rc1 kernel on iMX6SL processor. My filesystem is in >eMMC running SDR50. >Is anyone here encountered these problem and if there's any existing >patch that I can get?. hi, Do you use gcc 4.8.1? If so, maybe you should look at following link to see whether it's a similar issue. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 Liming Wang > >Regards, > >john > >[ 1552.394899] Unable to handle kernel NULL pointer dereference at >virtual address 0037 >[ 1552.403034] pgd = beef4000 >[ 1552.405855] [0037] *pgd=bef60831, *pte=, *ppte= >[ 1552.412245] Internal error: Oops: 17 [#1] ARM >[ 1552.416627] Modules linked in: bt8xxx(O) sd8xxx(O) mlan(O) >[ 1552.422249] CPU: 0 PID: 232 Comm: commsd Tainted: G O 3.13.0-rc1 >#7 >[ 1552.429409] task: bfbc7500 ti: bec96000 task.ti: bec96000 >[ 1552.434844] PC is at lookup_fast+0x5c/0x318 >[ 1552.439067] LR is at mark_held_locks+0x78/0x13c >[ 1552.443622] pc : [<80101184>]lr : [<80056e48>]psr: a00f0013 >[ 1552.443622] sp : bec97d88 ip : 00666e6f fp : bec97ddc >[ 1552.455124] r10: r9 : bec97e08 r8 : 80102d94 >[ 1552.460370] r7 : bec97e60 r6 : bf133ac8 r5 : bec97e60 r4 : bec97e00 >[ 1552.466918] r3 : bee4f01d r2 : r1 : r0 : >[ 1552.473471] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment >user >[ 1552.480629] Control: 10c53c7d Table: beef4059 DAC: 0015 >[ 1552.486397] Process commsd (pid: 232, stack limit = 0xbec96238) >[ 1552.492341] Stack: (0xbec97d88 to 0xbec98000) >[ 1552.496728] 7d80: 80102b94 80057108 bfb95310 >bf133ac8 bf15f4e8 bfb95310 >[ 1552.504936] 7da0: c08bb14d bee4f015 0008 bfbc7500 >bec97e08 0041 >[ 1552.513142] 7dc0: bec97e60 bec96020 bec96000 bec97e3c >bec97de0 80102d94 80101134 >[ 1552.521347] 7de0: bec97df8 800d982c bec96018 0010 >bec97e00 bec97e08 >[ 1552.529553] 7e00: 8026e25c 800d97e8 bee4f000 0ff0 80d4e3a4 >0001 bee4f000 bec97e60 >[ 1552.537758] 7e20: ff9c ff9c bec96000 bec97e5c >bec97e40 801033bc 80102c70 >[ 1552.545964] 7e40: bee4f000 0001 bec97e60 bec97f00 bec97ee4 >bec97e60 80105dc0 80103398 >[ 1552.554170] 7e60: bfb95310 bf133ac8 c08bb14d 000b bee4f015 >8005992c bfb95310 bf133398 >[ 1552.562375] 7e80: bf15f4e8 0041 0002 008a > 600f0013 bec96000 >[ 1552.570581] 7ea0: ffea bf8c1840 807b4430 80115444 801156e4 >8011563c 0008 >[ 1552.578786] 7ec0: bec97f04 733fe4e0 0001 ff9c 757e3810 >bec97f40 bec97efc bec97ee8 >[ 1552.586991] 7ee0: 80105e0c 80105d68 bc950fe0 bec97f2c >bec97f00 800faf64 80105df4 >[ 1552.595196] 7f00: 801156e4 80115420 bec97f54 733fe4e0 733ff8f0 >733fe61c 00c3 8000f504 >[ 1552.603402] 7f20: bec97f3c bec97f30 800fafe0 800faf1c bec97fa4 >bec97f40 800fb71c 800fafc4 >[ 1552.611608] 7f40: 8000f310 bfbc7500 733fe550 8000f458 733fe61c >00c3 bec97f84 bec97f68 >[ 1552.619813] 7f60: 80056f28 800a0270 733fe550 733ff8f0 733fe61c >00c3 bec97f94 bec97f88 >[ 1552.628019] 7f80: 80057110 80056f18 bec97f98 8000f458 >733fe550 bec97fa8 >[ 1552.636226] 7fa0: 8000f280 800fb704 733fe550 733ff8f0 757e3810 >733fe4e0 733fe550 0003 >[ 1552.644431] 7fc0: 733fe550 733ff8f0 733fe61c 00c3 >0002 733fe92c 0200 >[ 1552.652636] 7fe0: 00c3 733fe4d8 7579b7e5 7572e276 200f0030 >757e3810 bfffd821 bfffdc21 >[ 1552.660828] Backtrace: >[ 1552.663343] [<80101128>] (lookup_fast+0x0/0x318) from [<80102d94>] >(path_lookupat+0x130/0x728) >[ 1552.671994] [<80102c64>] (path_lookupat+0x0/0x728) from >[<801033bc>] (filename_lookup.isra.40+0x30/0x70) >[ 1552.681515] [<8010338c>] (filename_lookup.isra.40+0x0/0x70) from >[<80105dc0>] (user_path_at_empty+0x64/0x8c) >[ 1552.691361] r7:bec97f00 r6:bec97e60 r5:0001 r4:bee4f000 >[ 1552.697163] [<80105d5c>] (user_path_at_empty+0x0/0x8c) from >[<80105e0c>] (user_path_at+0x24/0x2c) >[ 1552.706053] r8:bec97f40 r7:757e3810 r6:ff9c r5:0001 r4:733fe4e0 >[ 1552.712927] [<80105de8>] (user_path_at+0x0/0x2c) from [<800faf64>] >(vfs_fstatat+0x54/0xa8) >[ 1552.721232] [<800faf10>] (vfs_fstatat+0x0/0xa8) from [<800fafe0>] >(vfs_stat+0x28/0x2c) >[ 1552.729167] r8:8000f504 r7:00c3 r6:733fe61c r5:733ff8f0 r4:733fe4e0 >[ 1552.736031] [<800fafb8>] (vfs_stat+0x0/0x2c) from [<800fb71c>] >(SyS_stat64+0x24/0x40) >[ 1552.743902] [<800fb6f8>] (SyS_stat64+0x0/0x40) from [<8000f280>] >(ret_fast_syscall+0x0/0x48) >[ 1552.752359] r4:733fe550 >[ 1552.754946] Code: eb00352d e350 e50b0038 0a80 (e5903038) >[ 1552.761270] ---[ end trace 02679086a39365e8 ]--- >[ 1552.765968] Kernel panic - not syncing: Fatal exception > >___ >linux-arm-kernel mailing list >linux-arm-ker...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list:
Re: [BUG] sched: tip/master show soft lockup while running multiple VM
On 01/22/2014 08:36 PM, Peter Zijlstra wrote: > On Wed, Jan 22, 2014 at 04:27:45PM +0800, Michael wang wrote: >> # CONFIG_PREEMPT_NONE is not set >> CONFIG_PREEMPT_VOLUNTARY=y >> # CONFIG_PREEMPT is not set > > Could you try the patch here: > > lkml.kernel.org/r/20140122102435.gh31...@twins.programming.kicks-ass.net > > I suspect its the same issue. Yup, it works. Regards, Michael Wang > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going beyond 4096 bytes
On Wed, 22 Jan 2014, Chris Mason wrote: On Wed, 2014-01-22 at 11:50 -0800, Andrew Morton wrote: On Wed, 22 Jan 2014 11:30:19 -0800 James Bottomley wrote: But this, I think, is the fundamental point for debate. If we can pull alignment and other tricks to solve 99% of the problem is there a need for radical VM surgery? Is there anything coming down the pipe in the future that may move the devices ahead of the tricks? I expect it would be relatively simple to get large blocksizes working on powerpc with 64k PAGE_SIZE. So before diving in and doing huge amounts of work, perhaps someone can do a proof-of-concept on powerpc (or ia64) with 64k blocksize. Maybe 5 drives in raid5 on MD, with 4K coming from each drive. Well aligned 16K IO will work, everything else will about the same as a rmw from a single drive. I think this is the key point to think about here. How will these new hard drive large block sizes differ from RAID stripes and SSD eraseblocks? In all of these cases there are very clear advantages to doing the writes in properly sized and aligned chunks that correspond with the underlying structure to avoid the RMW overhead. It's extremely unlikely that drive manufacturers will produce drives that won't work with any existing OS, so they are going to support smaller writes in firmware. If they don't, they won't be able to sell their drives to anyone running existing software. Given the Enterprise software upgrade cycle compared to the expanding storage needs, whatever they ship will have to work on OS and firmware releases that happened several years ago. I think what is needed is some way to be able to get a report on how man RMW cycles have to happen. Then people can work on ways to reduce this number and measure the results. I don't know if md and dm are currently smart enough to realize that the entire stripe is being overwritten and avoid the RMW cycle. If they can't, I would expect that once we start measuring it, they will gain such support. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -tip 0/8] perf-probe: Updates for handling local functions correctly
Hi, Here is a series of patches for handling local functions correctly in perf-probe. Issue 1) Current perf-probe can't handle probe-points for kprobes, since it uses symbol-based probe definition. The symbol based definition is easy to read and robust for differnt kernel and modules. However, when user gives a local function name which has several different instances, it may put probes on wrong (or unexpected) address. On the other hand, since uprobe events are based on the actual address, it can avoid this issue. E.g. In the case to probe t_show local functions (which has 4 different instances. # grep " t_show\$" /proc/kallsyms 810d9720 t t_show 810e2e40 t t_show 810ece30 t t_show 810f4ad0 t t_show # ./perf probe -f t_show \$vars Added new events: probe:t_show (on t_show with $vars) probe:t_show_1 (on t_show with $vars) probe:t_show_2 (on t_show with $vars) probe:t_show_3 (on t_show with $vars) You can now use it in all perf tools, such as: perf record -e probe:t_show_3 -aR sleep 1 OK, we have 4 different t_show()s. All functions have different arguments as below; # cat /sys/kernel/debug/tracing/kprobe_events p:probe/t_show t_show m=%di:u64 v=%si:u64 p:probe/t_show_1 t_show m=%di:u64 v=%si:u64 t=%si:u64 p:probe/t_show_2 t_show m=%di:u64 v=%si:u64 fmt=%si:u64 p:probe/t_show_3 t_show m=%di:u64 v=%si:u64 file=%si:u64 However, all of them have been put on the *same* address. # cat /sys/kernel/debug/kprobes/list 810d9720 k t_show+0x0[DISABLED] 810d9720 k t_show+0x0[DISABLED] 810d9720 k t_show+0x0[DISABLED] 810d9720 k t_show+0x0[DISABLED] oops... Issue 2) With the debuginfo, issue 1 can be solved by using address-based probe definition instead of symbol-based. However, without debuginfo, perf-probe can only use symbol-map in the binary (or kallsyms). The map provides symbol find methods, but it returns only the first matched symbol. To put probes on all functions which have given symbol, we need a symbol-list iterator for the map. E.g. (built perf with NO_DWARF=1) In the case to probe t_show and identity__map_ip in perf. # ./perf probe -a t_show Added new event: probe:t_show (on t_show) You can now use it in all perf tools, such as: perf record -e probe:t_show -aR sleep 1 # ./perf probe -x perf -a identity__map_ip no symbols found in /kbuild/ksrc/linux-3/tools/perf/perf, maybe install a debug package? Failed to load map. Error: Failed to add events. (-22) oops. Solutions) To solve the issue 1, this series changes perf probe to use address-based probe definition. This means that we also need to fix the --list options to analyze probe addresses instead of symbols (and that has been done in this series). E.g. with this series; # ./perf probe -f t_show \$vars Added new events: probe:t_show (on t_show with $vars) probe:t_show_1 (on t_show with $vars) probe:t_show_2 (on t_show with $vars) probe:t_show_3 (on t_show with $vars) You can now use it in all perf tools, such as: perf record -e probe:t_show_3 -aR sleep 1 # cat /sys/kernel/debug/tracing/kprobe_events p:probe/t_show 0x810d9720 m=%di:u64 v=%si:u64 p:probe/t_show_1 0x810e2e40 m=%di:u64 v=%si:u64 t=%si:u64 p:probe/t_show_2 0x810ece30 m=%di:u64 v=%si:u64 fmt=%si:u64 p:probe/t_show_3 0x810f4ad0 m=%di:u64 v=%si:u64 file=%si:u64 # cat /sys/kernel/debug/kprobes/list 810e2e40 k t_show+0x0[DISABLED] 810ece30 k t_show+0x0[DISABLED] 810f4ad0 k t_show+0x0[DISABLED] 810d9720 k t_show+0x0[DISABLED] This time we can see the events are set in different addresses. And for the issue 2, the last patch introduces symbol iterators for map, dso and symbols (since the symbol list is the symbols and it is included dso, and perf probe accesses dso via map). E.g. with this series (built perf with NO_DWARF=1); # ./perf probe -a t_show Added new events: probe:t_show (on t_show) probe:t_show_1 (on t_show) probe:t_show_2 (on t_show) probe:t_show_3 (on t_show) You can now use it in all perf tools, such as: perf record -e probe:t_show_3 -aR sleep 1 # ./perf probe -x perf -a identity__map_ip Added new events: probe_perf:identity__map_ip (on identity__map_ip in /kbuild/ksrc/linux-3/tools/perf/perf) probe_perf:identity__map_ip_1 (on identity__map_ip in /kbuild/ksrc/linux-3/tools/perf/perf) probe_perf:identity__map_ip_2 (on identity__map_ip in /kbuild/ksrc/linux-3/tools/perf/perf) probe_perf:identity__map_ip_3 (on identity__map_ip in /kbuild/ksrc/linux-3/tools/perf/perf) You can now use it in all perf tools, such as: perf record -e probe_perf:identity__map_ip_3 -aR sleep 1 Now, even without the debuginfo, both the kprobe and uprobe are set 4 different pl
[PATCH -tip 2/8] [BUGFIX] perf-tools: Load map before using map->map_ip
In map_groups__find_symbol() map->map_ip is used without
ensuring the map is loaded. Then the address passed
to map->map_ip isn't mapped at the first time.
E.g. below code always fails to get a symbol at the first call;
addr = /* Somewhere in the kernel text */
symbol_conf.try_vmlinux_path = true;
symbol__init();
host_machine = machine__new_host();
sym = machine__find_kernel_function(host_machine,
addr, NULL, NULL);
/* Note that machine__find_kernel_function calls
map_groups__find_symbol */
This ensures it by calling map__load before using it in
map_groups__find_symbol().
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/map.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 9b9bd71..6a805e7 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -386,7 +386,8 @@ struct symbol *map_groups__find_symbol(struct map_groups
*mg,
{
struct map *map = map_groups__find(mg, type, addr);
- if (map != NULL) {
+ /* Ensure map is loaded before using map->map_ip */
+ if (map != NULL && map__load(map, filter) >= 0) {
if (mapp != NULL)
*mapp = map;
return map__find_symbol(map, map->map_ip(map, addr), filter);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -tip 3/8] perf-probe: Show in what binaries/modules probes are set
Show the name of binary file or modules in which the probes
are set with --list option.
Without this change;
# ./perf probe -m drm drm_av_sync_delay
# ./perf probe -x perf dso__load_vmlinux
# ./perf probe -l
probe:drm_av_sync_delay (on drm_av_sync_delay)
probe_perf:dso__load_vmlinux (on 0x0006d110)
With this change;
# ./perf probe -l
probe:drm_av_sync_delay (on drm_av_sync_delay in drm)
probe_perf:dso__load_vmlinux (on 0x0006d110 in
/kbuild/ksrc/linux-3/tools/perf/perf)
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/probe-event.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 14c649df..2fb4486 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1742,7 +1742,8 @@ static struct strlist
*get_probe_trace_command_rawlist(int fd)
}
/* Show an event */
-static int show_perf_probe_event(struct perf_probe_event *pev)
+static int show_perf_probe_event(struct perf_probe_event *pev,
+const char *module)
{
int i, ret;
char buf[128];
@@ -1758,6 +1759,8 @@ static int show_perf_probe_event(struct perf_probe_event
*pev)
return ret;
printf(" %-20s (on %s", buf, place);
+ if (module)
+ printf(" in %s", module);
if (pev->nargs > 0) {
printf(" with");
@@ -1795,7 +1798,8 @@ static int __show_perf_probe_events(int fd, bool
is_kprobe)
ret = convert_to_perf_probe_event(&tev, &pev,
is_kprobe);
if (ret >= 0)
- ret = show_perf_probe_event(&pev);
+ ret = show_perf_probe_event(&pev,
+ tev.point.module);
}
clear_perf_probe_event(&pev);
clear_probe_trace_event(&tev);
@@ -1994,7 +1998,7 @@ static int __add_probe_trace_events(struct
perf_probe_event *pev,
group = pev->group;
pev->event = tev->event;
pev->group = tev->group;
- show_perf_probe_event(pev);
+ show_perf_probe_event(pev, tev->point.module);
/* Trick here - restore current event/group */
pev->event = (char *)event;
pev->group = (char *)group;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -tip 5/8] perf-probe: Show source level information for address only kprobes
Show the source code level information for address only kprobe
events. Currently the perf probe shows such information only
for symbol-based probes. With this change, perf-probe correctly
parses the address-based events and tries to find the actual
lines of code from the debuginfo.
E.g. without this patch;
# ./perf probe -l
probe:t_show (on 0x810d9720 with m v)
probe:t_show_1 (on 0x810e2e40 with m v t)
probe:t_show_2 (on 0x810ece30 with m v fmt)
probe:t_show_3 (on 0x810f4ad0 with m v file)
With this patch;
# ./perf probe -l
probe:t_show (on t_show@linux-3/kernel/trace/ftrace.c with m v)
probe:t_show_1 (on t_show@linux-3/kernel/trace/trace.c with m v t)
probe:t_show_2 (on t_show@kernel/trace/trace_printk.c with m v fmt)
probe:t_show_3 (on t_show@kernel/trace/trace_events.c with m v file)
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/probe-event.c | 87 ++---
1 file changed, 56 insertions(+), 31 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 92ab688..3470934 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -153,7 +153,7 @@ static struct dso *kernel_get_module_dso(const char *module)
struct map *map;
const char *vmlinux_name;
- if (module) {
+ if (module && strcmp(module, "kernel") != 0) {
list_for_each_entry(dso, &host_machine->kernel_dsos, node) {
if (strncmp(dso->short_name + 1, module,
dso->short_name_len - 2) == 0)
@@ -220,12 +220,22 @@ out:
static int convert_to_perf_probe_point(struct probe_trace_point *tp,
struct perf_probe_point *pp)
{
- pp->function = strdup(tp->symbol);
+ char buf[128];
+ int ret;
+ if (tp->symbol) {
+ pp->function = strdup(tp->symbol);
+ pp->offset = tp->offset;
+ } else {
+ ret = e_snprintf(buf, 128, "0x%" PRIx64, (u64)tp->address);
+ if (ret < 0)
+ return ret;
+ pp->function = strdup(buf);
+ pp->offset = 0;
+ }
if (pp->function == NULL)
return -ENOMEM;
- pp->offset = tp->offset;
pp->retprobe = tp->retprobe;
return 0;
@@ -261,28 +271,35 @@ static int kprobe_convert_to_perf_probe(struct
probe_trace_point *tp,
{
struct symbol *sym;
struct map *map;
- u64 addr;
- int ret = -ENOENT;
+ u64 addr = tp->address;
+ int ret;
struct debuginfo *dinfo;
- sym = __find_kernel_function_by_name(tp->symbol, &map);
- if (sym) {
+ if (!addr) {
+ sym = __find_kernel_function_by_name(tp->symbol, &map);
+ if (!sym) {
+ ret = -ENOENT;
+ goto error;
+ }
addr = map->unmap_ip(map, sym->start + tp->offset);
- pr_debug("try to find %s+%ld@%" PRIx64 "\n", tp->symbol,
-tp->offset, addr);
+ }
+
+ pr_debug("try to find information at %" PRIx64 " in %s\n", addr,
+tp->module ? : "kernel");
- dinfo = debuginfo__new_online_kernel(addr);
- if (dinfo) {
- ret = debuginfo__find_probe_point(dinfo,
+ dinfo = debuginfo__new_online_kernel(addr);
+ if (dinfo) {
+ ret = debuginfo__find_probe_point(dinfo,
(unsigned long)addr, pp);
- debuginfo__delete(dinfo);
- } else {
- pr_debug("Failed to open debuginfo at 0x%" PRIx64 "\n",
-addr);
- ret = -ENOENT;
- }
+ debuginfo__delete(dinfo);
+ } else {
+ pr_debug("Failed to open debuginfo at 0x%" PRIx64 "\n",
+addr);
+ ret = -ENOENT;
}
+
if (ret <= 0) {
+error:
pr_debug("Failed to find corresponding probes from "
"debuginfo. Use kprobe event information.\n");
return convert_to_perf_probe_point(tp, pp);
@@ -745,10 +762,13 @@ static int kprobe_convert_to_perf_probe(struct
probe_trace_point *tp,
{
struct symbol *sym;
- sym = __find_kernel_function_by_name(tp->symbol, NULL);
- if (!sym) {
- pr_err("Failed to find symbol %s in kernel.\n", tp->symbol);
- return -ENOENT;
+ if (tp->symbol) {
+ sym = __find_kernel_function_by_name(tp->symbol, NULL);
+ if (!sym) {
+ pr_err("Failed to find symbol %s in kernel.\n",
+ tp->symbol);
+ return -ENOENT;
+
[PATCH -tip 7/8] perf-probe: Show source-level or symbol-level info for uprobes
Show source-level or symbol-level information for uprobe events.
Without this change;
# ./perf probe -l
probe_perf:dso__load_vmlinux (on 0x0006d110 in
/kbuild/ksrc/linux-3/tools/perf/perf)
With this change;
# ./perf probe -l
probe_perf:dso__load_vmlinux (on dso__load_vmlinux@util/symbol.c in
/kbuild/ksrc/linux-3/tools/perf/perf)
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/probe-event.c | 149 -
1 file changed, 88 insertions(+), 61 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index bf1d73b..84c1807 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -224,42 +224,6 @@ out:
return ret;
}
-static int convert_to_perf_probe_point(struct probe_trace_point *tp,
- struct perf_probe_point *pp)
-{
- char buf[128];
- int ret;
- struct symbol *sym;
- struct map *map;
- u64 addr;
-
- if (!tp->symbol) {
- sym = __find_kernel_function(tp->address, &map);
- if (sym) {
- pp->function = strdup(sym->name);
- addr = map->unmap_ip(map, sym->start);
- pp->offset = tp->address - addr;
- } else {
- ret = e_snprintf(buf, 128, "0x%" PRIx64,
-(u64)tp->address);
- if (ret < 0)
- return ret;
- pp->function = strdup(buf);
- pp->offset = 0;
- }
- } else {
- pp->function = strdup(tp->symbol);
- pp->offset = tp->offset;
- }
-
- if (pp->function == NULL)
- return -ENOMEM;
-
- pp->retprobe = tp->retprobe;
-
- return 0;
-}
-
#ifdef HAVE_DWARF_SUPPORT
/* Open new debuginfo of given module */
static struct debuginfo *open_debuginfo(const char *module)
@@ -285,8 +249,9 @@ static struct debuginfo *open_debuginfo(const char *module)
* Convert trace point to probe point with debuginfo
* Currently only handles kprobes.
*/
-static int kprobe_convert_to_perf_probe(struct probe_trace_point *tp,
- struct perf_probe_point *pp)
+static int find_perf_probe_point_from_dwarf(struct probe_trace_point *tp,
+ struct perf_probe_point *pp,
+ bool is_kprobe)
{
struct symbol *sym;
struct map *map;
@@ -306,7 +271,11 @@ static int kprobe_convert_to_perf_probe(struct
probe_trace_point *tp,
pr_debug("try to find information at %" PRIx64 " in %s\n", addr,
tp->module ? : "kernel");
- dinfo = debuginfo__new_online_kernel(addr);
+ if (is_kprobe)
+ dinfo = debuginfo__new_online_kernel(addr);
+ else
+ dinfo = open_debuginfo(tp->module);
+
if (dinfo) {
ret = debuginfo__find_probe_point(dinfo,
(unsigned long)addr, pp);
@@ -319,9 +288,8 @@ static int kprobe_convert_to_perf_probe(struct
probe_trace_point *tp,
if (ret <= 0) {
error:
- pr_debug("Failed to find corresponding probes from "
-"debuginfo. Use kprobe event information.\n");
- return convert_to_perf_probe_point(tp, pp);
+ pr_debug("Failed to find corresponding probes from
debuginfo.\n");
+ return ret ? : -ENOENT;
}
pp->retprobe = tp->retprobe;
@@ -776,21 +744,12 @@ out:
#else /* !HAVE_DWARF_SUPPORT */
-static int kprobe_convert_to_perf_probe(struct probe_trace_point *tp,
- struct perf_probe_point *pp)
+static int
+find_perf_probe_point_from_dwarf(struct probe_trace_point *tp __maybe_unused,
+struct perf_probe_point *pp __maybe_unused,
+bool is_kprobe __maybe_unused)
{
- struct symbol *sym;
-
- if (tp->symbol) {
- sym = __find_kernel_function_by_name(tp->symbol, NULL);
- if (!sym) {
- pr_err("Failed to find symbol %s in kernel.\n",
- tp->symbol);
- return -ENOENT;
- }
- }
-
- return convert_to_perf_probe_point(tp, pp);
+ return -ENOSYS;
}
static int try_to_find_probe_trace_events(struct perf_probe_event *pev,
@@ -1609,6 +1568,78 @@ error:
return NULL;
}
+static int find_perf_probe_point_from_map(struct probe_trace_point *tp,
+ struct perf_probe_point *pp,
+ bool is_kprobe)
+{
+ struct symbol *sym = NULL;
+ struct map *map = NULL;
+ u64 addr;
+ int ret = 0;
+
+ if (is_kprobe)
+
[PATCH -tip 8/8] perf-probe: Allow to add events on the local functions
Allow to add events on the local functions without debuginfo.
(With the debuginfo, we can add events even on inlined functions)
Currently, probing on local functions requires debuginfo to
locate actual address. It is also possible without debuginfo since
we have symbol maps.
Without this change;
# ./perf probe -a t_show
Added new event:
probe:t_show (on t_show)
You can now use it in all perf tools, such as:
perf record -e probe:t_show -aR sleep 1
# ./perf probe -x perf -a identity__map_ip
no symbols found in /kbuild/ksrc/linux-3/tools/perf/perf, maybe install a debug
package?
Failed to load map.
Error: Failed to add events. (-22)
As the above results, perf probe just put one event
on the first found symbol for kprobe event. Moreover,
for uprobe event, perf probe failed to find local
functions.
With this change;
# ./perf probe -a t_show
Added new events:
probe:t_show (on t_show)
probe:t_show_1 (on t_show)
probe:t_show_2 (on t_show)
probe:t_show_3 (on t_show)
You can now use it in all perf tools, such as:
perf record -e probe:t_show_3 -aR sleep 1
# ./perf probe -x perf -a identity__map_ip
Added new events:
probe_perf:identity__map_ip (on identity__map_ip in
/kbuild/ksrc/linux-3/tools/perf/perf)
probe_perf:identity__map_ip_1 (on identity__map_ip in
/kbuild/ksrc/linux-3/tools/perf/perf)
probe_perf:identity__map_ip_2 (on identity__map_ip in
/kbuild/ksrc/linux-3/tools/perf/perf)
probe_perf:identity__map_ip_3 (on identity__map_ip in
/kbuild/ksrc/linux-3/tools/perf/perf)
You can now use it in all perf tools, such as:
perf record -e probe_perf:identity__map_ip_3 -aR sleep 1
Now we succeed to put events on every given local functions
for both kprobes and uprobes. :)
Note that this also introduces some symbol rbtree
iteration macros; symbols__for_each, dso__for_each_symbol,
and map__for_each_symbol. These are for walking through
the symbol list in a map.
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/dso.h | 10 +
tools/perf/util/map.h | 10 +
tools/perf/util/probe-event.c | 351 ++---
tools/perf/util/symbol.h | 11 +
4 files changed, 183 insertions(+), 199 deletions(-)
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index cd7d6f0..ab06f1c 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -102,6 +102,16 @@ struct dso {
char name[0];
};
+/* dso__for_each_symbol - iterate over the symbols of given type
+ *
+ * @dso: the 'struct dso *' in which symbols itereated
+ * @pos: the 'struct symbol *' to use as a loop cursor
+ * @n: the 'struct rb_node *' to use as a temporary storage
+ * @type: the 'enum map_type' type of symbols
+ */
+#define dso__for_each_symbol(dso, pos, n, type)\
+ symbols__for_each_entry(&(dso)->symbols[(type)], pos, n)
+
static inline void dso__set_loaded(struct dso *dso, enum map_type type)
{
dso->loaded |= (1 << type);
diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h
index 18068c6..ef18a48 100644
--- a/tools/perf/util/map.h
+++ b/tools/perf/util/map.h
@@ -89,6 +89,16 @@ u64 map__objdump_2mem(struct map *map, u64 ip);
struct symbol;
+/* map__for_each_symbol - iterate over the symbols in the given map
+ *
+ * @map: the 'struct map *' in which symbols itereated
+ * @pos: the 'struct symbol *' to use as a loop cursor
+ * @n: the 'struct rb_node *' to use as a temporary storage
+ * Note: caller must ensure map->dso is not NULL (map is loaded).
+ */
+#define map__for_each_symbol(map, pos, n) \
+ dso__for_each_symbol(map->dso, pos, n, map->type)
+
typedef int (*symbol_filter_t)(struct map *map, struct symbol *sym);
void map__init(struct map *map, enum map_type type,
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 84c1807..93087d7 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -70,8 +70,6 @@ static int e_snprintf(char *str, size_t size, const char
*format, ...)
}
static char *synthesize_perf_probe_point(struct perf_probe_point *pp);
-static int convert_name_to_addr(struct perf_probe_event *pev,
- const char *exec);
static void clear_probe_trace_event(struct probe_trace_event *tev);
static struct machine *host_machine;
@@ -119,14 +117,6 @@ static void exit_symbol_maps(void)
}
/* Caller must call init_symbol_maps before use this */
-static struct symbol *__find_kernel_function_by_name(const char *name,
-struct map **mapp)
-{
- return machine__find_kernel_function_by_name(host_machine, name, mapp,
-NULL);
-}
-
-/* Caller must call init_symbol_maps before use this */
static struct symbol *__find_kernel_function(u64 addr, struct map **mapp)
{
return machine__find_kernel_function(host_machine, addr, mapp
[PATCH -tip 6/8] perf-probe: Show symbol+offset for address only kprobes
Show the symbol+offset information for address only kprobe
events when --list operation without debuginfo. Currently
those events are shown by the address itself. With this change
perf probe finds symbols on those addresses and shows it.
E.g. without this change (when debuginfo is not available);
# ./perf probe -l
probe:t_show (on 0x810d9720 with m v)
probe:t_show_1 (on 0x810e2e40 with m v t)
probe:t_show_2 (on 0x810ece30 with m v fmt)
probe:t_show_3 (on 0x810f4ad0 with m v file)
With this change;
# ./perf probe -l
probe:t_show (on t_show with m v)
probe:t_show_1 (on t_show with m v t)
probe:t_show_2 (on t_show with m v fmt)
probe:t_show_3 (on t_show with m v file)
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/probe-event.c | 35 +++
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 3470934..bf1d73b 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -118,6 +118,7 @@ static void exit_symbol_maps(void)
symbol__exit();
}
+/* Caller must call init_symbol_maps before use this */
static struct symbol *__find_kernel_function_by_name(const char *name,
struct map **mapp)
{
@@ -125,6 +126,12 @@ static struct symbol *__find_kernel_function_by_name(const
char *name,
NULL);
}
+/* Caller must call init_symbol_maps before use this */
+static struct symbol *__find_kernel_function(u64 addr, struct map **mapp)
+{
+ return machine__find_kernel_function(host_machine, addr, mapp, NULL);
+}
+
static struct map *kernel_get_module_map(const char *module)
{
struct rb_node *nd;
@@ -222,17 +229,29 @@ static int convert_to_perf_probe_point(struct
probe_trace_point *tp,
{
char buf[128];
int ret;
-
- if (tp->symbol) {
+ struct symbol *sym;
+ struct map *map;
+ u64 addr;
+
+ if (!tp->symbol) {
+ sym = __find_kernel_function(tp->address, &map);
+ if (sym) {
+ pp->function = strdup(sym->name);
+ addr = map->unmap_ip(map, sym->start);
+ pp->offset = tp->address - addr;
+ } else {
+ ret = e_snprintf(buf, 128, "0x%" PRIx64,
+(u64)tp->address);
+ if (ret < 0)
+ return ret;
+ pp->function = strdup(buf);
+ pp->offset = 0;
+ }
+ } else {
pp->function = strdup(tp->symbol);
pp->offset = tp->offset;
- } else {
- ret = e_snprintf(buf, 128, "0x%" PRIx64, (u64)tp->address);
- if (ret < 0)
- return ret;
- pp->function = strdup(buf);
- pp->offset = 0;
}
+
if (pp->function == NULL)
return -ENOMEM;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -tip 4/8] perf-probe: Use the actual address instead of the symbol name
Since several local symbols can have same name (e.g. t_show),
we need to use the actual address instead of symbol name for
those points. Note that this works only with debuginfo.
E.g. without this change;
# ./perf probe -a t_show \$vars
Added new events:
probe:t_show (on t_show with $vars)
probe:t_show_1 (on t_show with $vars)
probe:t_show_2 (on t_show with $vars)
probe:t_show_3 (on t_show with $vars)
You can now use it in all perf tools, such as:
perf record -e probe:t_show_3 -aR sleep 1
OK, we have 4 different t_show()s. All functions have
different arguments as below;
# cat /sys/kernel/debug/tracing/kprobe_events
p:probe/t_show t_show m=%di:u64 v=%si:u64
p:probe/t_show_1 t_show m=%di:u64 v=%si:u64 t=%si:u64
p:probe/t_show_2 t_show m=%di:u64 v=%si:u64 fmt=%si:u64
p:probe/t_show_3 t_show m=%di:u64 v=%si:u64 file=%si:u64
However, all of them have been put on the *same* address.
# cat /sys/kernel/debug/kprobes/list
810d9720 k t_show+0x0[DISABLED]
810d9720 k t_show+0x0[DISABLED]
810d9720 k t_show+0x0[DISABLED]
810d9720 k t_show+0x0[DISABLED]
With this change;
# ./perf probe -a t_show \$vars
Added new events:
probe:t_show (on t_show with $vars)
probe:t_show_1 (on t_show with $vars)
probe:t_show_2 (on t_show with $vars)
probe:t_show_3 (on t_show with $vars)
You can now use it in all perf tools, such as:
perf record -e probe:t_show_3 -aR sleep 1
# cat /sys/kernel/debug/tracing/kprobe_events
p:probe/t_show 0x810d9720 m=%di:u64 v=%si:u64
p:probe/t_show_1 0x810e2e40 m=%di:u64 v=%si:u64 t=%si:u64
p:probe/t_show_2 0x810ece30 m=%di:u64 v=%si:u64 fmt=%si:u64
p:probe/t_show_3 0x810f4ad0 m=%di:u64 v=%si:u64 file=%si:u64
# cat /sys/kernel/debug/kprobes/list
810e2e40 k t_show+0x0[DISABLED]
810ece30 k t_show+0x0[DISABLED]
810f4ad0 k t_show+0x0[DISABLED]
810d9720 k t_show+0x0[DISABLED]
This time, each event is put in different address
correctly.
Note that currently this doesn't support address-based
probe on modules (thus the probes on modules are symbol
based), since it requires relative address probe syntax
for kprobe-tracer, and it doesn't implemented yet.
One more note, this allows us to put events on correct
address, but --list option should be updated to show
correct corresponding source code.
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/probe-event.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 2fb4486..92ab688 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1529,20 +1529,27 @@ char *synthesize_probe_trace_command(struct
probe_trace_event *tev)
if (buf == NULL)
return NULL;
- if (tev->uprobes)
- len = e_snprintf(buf, MAX_CMDLEN, "%c:%s/%s %s:%s",
-tp->retprobe ? 'r' : 'p',
-tev->group, tev->event,
+ len = e_snprintf(buf, MAX_CMDLEN, "%c:%s/%s ", tp->retprobe ? 'r' : 'p',
+tev->group, tev->event);
+ if (len <= 0)
+ goto error;
+
+ /* Use the real address, except for kernel modules */
+ if (tp->address && !(tp->module && !tev->uprobes))
+ ret = e_snprintf(buf + len, MAX_CMDLEN, "%s%s0x%lx",
+tp->module ?: "", tp->module ? ":" : "",
+tp->address);
+ else if (tev->uprobes)
+ ret = e_snprintf(buf + len, MAX_CMDLEN, "%s:%s",
tp->module, tp->symbol);
else
- len = e_snprintf(buf, MAX_CMDLEN, "%c:%s/%s %s%s%s+%lu",
-tp->retprobe ? 'r' : 'p',
-tev->group, tev->event,
+ ret = e_snprintf(buf + len, MAX_CMDLEN, "%s%s%s+%lu",
tp->module ?: "", tp->module ? ":" : "",
tp->symbol, tp->offset);
- if (len <= 0)
+ if (ret <= 0)
goto error;
+ len += ret;
for (i = 0; i < tev->nargs; i++) {
ret = synthesize_probe_trace_arg(&tev->args[i], buf + len,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
