[PATCH v2] btrfs: use kmalloc for lzo de/compress buffer
The size of de/compress buffer is small enough to use kmalloc.
Allocating it with kmalloc rather than vmalloc is preferred.
This patch depends on my previous patch, “btrfs: fix decompress buffer size”.
v2: Using vmalloc for "workspace->mem" due to the size limit.
Signed-off-by: Kyungsik Lee
Cc: David Sterba
---
fs/btrfs/lzo.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/lzo.c b/fs/btrfs/lzo.c
index 223893a..b2e 100644
--- a/fs/btrfs/lzo.c
+++ b/fs/btrfs/lzo.c
@@ -40,8 +40,8 @@ static void lzo_free_workspace(struct list_head *ws)
{
struct workspace *workspace = list_entry(ws, struct workspace, list);
- vfree(workspace->buf);
- vfree(workspace->cbuf);
+ kfree(workspace->buf);
+ kfree(workspace->cbuf);
vfree(workspace->mem);
kfree(workspace);
}
@@ -55,8 +55,9 @@ static struct list_head *lzo_alloc_workspace(void)
return ERR_PTR(-ENOMEM);
workspace->mem = vmalloc(LZO1X_MEM_COMPRESS);
- workspace->buf = vmalloc(PAGE_CACHE_SIZE);
- workspace->cbuf = vmalloc(lzo1x_worst_compress(PAGE_CACHE_SIZE));
+ workspace->buf = kmalloc(PAGE_CACHE_SIZE, GFP_NOFS);
+ workspace->cbuf = kmalloc(lzo1x_worst_compress(PAGE_CACHE_SIZE),
+ GFP_NOFS);
if (!workspace->mem || !workspace->buf || !workspace->cbuf)
goto fail;
--
1.8.0.3
--
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 0/15] power aware scheduling
On 02/18/2013 01:07 PM, Alex Shi wrote: > Since the simplification of fork/exec/wake balancing has much arguments, > I removed that part in the patch set. > > This patch set implement/consummate the rough power aware scheduling > proposal: https://lkml.org/lkml/2012/8/13/139. Just review the great summary of the conversation on this proposal. http://lwn.net/Articles/512487/ One of advantage of this patch is that it bases on the general sched domain/groups architecture, so, if other hardware platforms, like ARM, has different hardware setting, it can be represented as specific domain flags. and then be treated specific in scheduling. The scheduling is natural and easy to expend to that. And guess the big.LITTLE arch also can be represented by cpu power, if so, the 'balance' policy just fit them since it judges if the sched domain/group is full by domain/group's capacity. Also adding a answer for policy automatic change feature: --- The 'balance/powersaving' is automatic power friendly scheduling, since system will auto bypass power scheduling when cpus utilisation in a sched domain is beyond the domain's cpu weight (powersaving) or beyond the domain's capacity (balance). There is no always enabled power scheduling, since the patchset bases on 'race to idle'. -- 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/
Re: BUG at net/sunrpc/svc_xprt.c:921 (another one)
On Sunday 17 of February 2013 10:54:20 J. Bruce Fields wrote: > On Fri, Feb 15, 2013 at 08:33:14PM +0100, Paweł Sikora wrote: > > On Tuesday 12 of February 2013 15:52:17 J. Bruce Fields wrote: > > > On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote: > > > > Got it again, this time on a different system > > > > running mostly the same software. > > > > > > Mark, Paweł, Tom, could any of you confirm whether this helps? > > > > with this patch i can confirm a 2 day uptime w/o any oopses. > > > > Thanks for the report.--b. please push this patch to the 3.7.y stable kernel. -- 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 v4 3/6] mfd: Add ChromeOS EC I2C driver
Hi,
On Sat, Feb 16, 2013 at 06:46:53AM -0800, Simon Glass wrote:
> Hi,
>
> On Sat, Feb 16, 2013 at 1:06 AM, Felipe Balbi wrote:
> > On Fri, Feb 15, 2013 at 08:16:09PM -0800, Simon Glass wrote:
> >> This uses an I2C bus to talk to the ChromeOS EC. The protocol
> >> is defined by the EC and is fairly simple, with a length byte,
> >> checksum, command byte and version byte (to permit easy creation
> >> of new commands).
> >>
> >> Signed-off-by: Simon Glass
> >> Signed-off-by: Che-Liang Chiou
> >
> > the driver you're adding here is no where near being an MFD device. MFD
> > children shouldn't be under drivers/mfd/. Please find a proper location
> > for this driver.
>
> I think you might be misunderstanding the intent here. This driver is
> actually not an MFD child, but a real MFD device. The children are
> things like the cros_ec_keyb which use this device to access to the EC
> and provide a function to the kernel (such as keyboard, EC flash
> access and so on). They are indeed somewhere else in the tree.
>
> This driver sits in MFD for that reason, and provides a way to talk to
> the EC over I2C. Rather than duplicate the code in each bus driver
> (I2C, SPI, LPC) we have chosen to put that core code in a common file,
> cros_ec, So one way to think of it is that we have several transports
> which each provides an abstracted interface to an EC.
>
> There are several examples in drivers/mfd where this is done. For example:
>
> da9052_i2c.c and da9052_spi.c each provide an MFD driver, which calls
> da9052_device_init() in da50542-core.c.
>
> and there are many others in MFD which use this approach, for example:
>
> drivers/mfd/wm831x-core.c
> drivers/mfd/wm831x-i2c.c
> drivers/mfd/wm831x-spi.c
>
> and
>
> drivers/mfd/tps65912-core.c
> drivers/mfd/tps65912-i2c.c
> drivers/mfd/tps65912-spi.c
>
> The intent is to keep the communications separate from the function
> provided by the device.
fair enough.
> >> +/* Since I2C can be unreliable, we retry commands */
> >> +#define COMMAND_MAX_TRIES 3
> >
> > unreliable in what way ? Are you sure you haven't found a bug on your
> > embedded controller or your i2c controller driver ?
>
> Well those bugs were fixed. I think this is here for safety just in
> case is this bad?
I guess it looks a bit weird, specially since that retry mechanism
should be on the i2c bus driver.
> >> +static const char *cros_ec_get_phys_name(struct cros_ec_device *ec_dev)
> >> +{
> >> + struct i2c_client *client = ec_dev->priv;
> >> +
> >> + return client->adapter->name;
> >> +}
> >> +
> >> +static struct device *cros_ec_get_parent(struct cros_ec_device *ec_dev)
> >> +{
> >> + struct i2c_client *client = ec_dev->priv;
> >> +
> >> + return >dev;
> >> +}
> >
> > not sure you should allow other layers to fiddle with these. Specially
> > the parent device ointer.
>
> This is the parent device for any children. Some MFD children will
> want to know their parent. I can just add it to the structure I think.
they can know their parent by using "dev->parent". Also you should be
creating your children with proper mfd_add_devices() call.
--
balbi
signature.asc
Description: Digital signature
Re: [v3.8 Regression] watchdog: sp5100_tco: Add SB8x0 chipset support
I've requested a digital image or screen capture of the panic. Is there any additional debug information you thing would be helpful? Thanks, Joe On Sun, Feb 17, 2013 at 10:13 PM, Joseph Salisbury wrote: > On 02/17/2013 04:44 AM, Tanaka Takahisa wrote: >> >> Hi Joseph, >> >> 2013/2/15 Joseph Salisbury : >>> >>> On 02/15/2013 02:32 AM, Wim Van Sebroeck wrote: Hi Joseph, > A bug was opened against the Ubuntu kernel[0]. It was found that > reverting the following commit resolved this bug: > > commit 740fbddf5c3f9ad8b23c5d917ba1cc7e376a5104 > Author: Takahisa Tanaka > Date: Sun Dec 2 14:33:18 2012 +0900 > > watchdog: sp5100_tco: Add SB8x0 chipset support > > > The regression was introduced as of v3.8-rc1. > > I see that you are the author of this patch, so I wanted to run this by > you. I was thinking of requesting a revert for v3.8, but I wanted to > get your feedback first. Please check out the attached patches first (They are allready in linux-next). >>> >>> Thanks for the feedback, Wim. I'll let you know if the patches resolve >>> this >>> bug. >>> >>> Other references: Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 Kind regards, Wim. >> >> Thank you for your information, and sorry for the late reply. >> >> I think that I will get rid of code that re-programming the chipset >> registers, if my patch set doesn't resolve the problem. >> I'm waiting for your reply at the moment. >> >> >> Regards, >> Takahisa > > Hi Takahisa, > > The bug report tested a kernel with the patches. However, he reports the > kernel panic still occurs[0]. > > Thanks, > > Joe > > [0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1116835 > > -- > 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/
[PATCH v3 3/4] regulator: core: use regulator_ena_pin member
The regulator_dev has regulator_enable_gpio structure.
'ena_gpio' and 'ena_gpio_invert' were moved to in regulator_enable_gpio.
regulator_dev ---> regulator_enable_gpio
.ena_gpio .gpio
.ena_gpio_invert .ena_gpio_invert
Pointer, 'ena_pin' is used for checking valid enable GPIO pin.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/core.c |6 +++---
include/linux/regulator/driver.h |2 --
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 57d434d..6c8c824 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1945,7 +1945,7 @@ EXPORT_SYMBOL_GPL(regulator_disable_regmap);
static int _regulator_is_enabled(struct regulator_dev *rdev)
{
/* A GPIO control always takes precedence */
- if (rdev->ena_gpio)
+ if (rdev->ena_pin)
return rdev->ena_gpio_state;
/* If we don't know then assume that the regulator is always on */
@@ -3344,7 +3344,7 @@ static int add_regulator_attributes(struct regulator_dev
*rdev)
if (status < 0)
return status;
}
- if (rdev->ena_gpio || ops->is_enabled) {
+ if (rdev->ena_pin || ops->is_enabled) {
status = device_create_file(dev, _attr_state);
if (status < 0)
return status;
@@ -3556,7 +3556,7 @@ regulator_register(const struct regulator_desc
*regulator_desc,
if (config->ena_gpio_flags & GPIOF_OUT_INIT_HIGH)
rdev->ena_gpio_state = 1;
- if (rdev->ena_gpio_invert)
+ if (config->ena_gpio_invert)
rdev->ena_gpio_state = !rdev->ena_gpio_state;
}
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index a467d11..7b7aeec 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -302,8 +302,6 @@ struct regulator_dev {
struct dentry *debugfs;
struct regulator_enable_gpio *ena_pin;
- int ena_gpio;
- unsigned int ena_gpio_invert:1;
unsigned int ena_gpio_state:1;
};
--
1.7.9.5
Best Regards,
Milo
--
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 v3 2/4] regulator: core: manage enable GPIO list
To support shared enable GPIO pin, replace GPIO code with new static functions
Reference count: 'enable_count'
Balance the reference count of each GPIO and actual pin control.
The count is incremented with enabling GPIO.
On the other hand, it is decremented on disabling GPIO.
Actual GPIO pin is enabled at the initial use.(enable_count = 0)
The pin is disabled if it is not used(shared) any more. (enable_count <=1)
Regardless of the enable count, update GPIO state of the regulator.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/core.c | 50 --
1 file changed, 44 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 71d6adc..57d434d 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1529,6 +1529,42 @@ static void regulator_ena_gpio_free(struct regulator_dev
*rdev)
}
}
+/**
+ * Balance enable_count of each GPIO and actual GPIO pin control.
+ * GPIO is enabled in case of initial use. (enable_count is 0)
+ * GPIO is disabled when it is not shared any more. (enable_count <= 1)
+ */
+static int regulator_ena_gpio_ctrl(struct regulator_dev *rdev, bool enable)
+{
+ struct regulator_enable_gpio *pin = rdev->ena_pin;
+
+ if (!pin)
+ return -EINVAL;
+
+ if (enable) {
+ /* Enable GPIO at initial use */
+ if (pin->enable_count == 0)
+ gpio_set_value_cansleep(pin->gpio,
+ !pin->ena_gpio_invert);
+
+ pin->enable_count++;
+ } else {
+ if (pin->enable_count > 1) {
+ pin->enable_count--;
+ return 0;
+ }
+
+ /* Disable GPIO if not used */
+ if (pin->enable_count <= 1) {
+ gpio_set_value_cansleep(pin->gpio,
+ pin->ena_gpio_invert);
+ pin->enable_count = 0;
+ }
+ }
+
+ return 0;
+}
+
static int _regulator_do_enable(struct regulator_dev *rdev)
{
int ret, delay;
@@ -1544,9 +1580,10 @@ static int _regulator_do_enable(struct regulator_dev
*rdev)
trace_regulator_enable(rdev_get_name(rdev));
- if (rdev->ena_gpio) {
- gpio_set_value_cansleep(rdev->ena_gpio,
- !rdev->ena_gpio_invert);
+ if (rdev->ena_pin) {
+ ret = regulator_ena_gpio_ctrl(rdev, true);
+ if (ret < 0)
+ return ret;
rdev->ena_gpio_state = 1;
} else if (rdev->desc->ops->enable) {
ret = rdev->desc->ops->enable(rdev);
@@ -1648,9 +1685,10 @@ static int _regulator_do_disable(struct regulator_dev
*rdev)
trace_regulator_disable(rdev_get_name(rdev));
- if (rdev->ena_gpio) {
- gpio_set_value_cansleep(rdev->ena_gpio,
- rdev->ena_gpio_invert);
+ if (rdev->ena_pin) {
+ ret = regulator_ena_gpio_ctrl(rdev, false);
+ if (ret < 0)
+ return ret;
rdev->ena_gpio_state = 0;
} else if (rdev->desc->ops->disable) {
--
1.7.9.5
Best Regards,
Milo
--
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 v3 4/4] regulator: lp8788-ldo: use ena_pin of regulator-core for external control
Regulator core driver provides enable GPIO control for enabling/disabling a
regulator. Now, enable GPIO is shared among regulators.
Use this internal working, so unnecessary code are removed.
GPIO enable pin configurations are added in digital LDO and analog LDO drivers.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp8788-ldo.c | 98 +++-
1 file changed, 17 insertions(+), 81 deletions(-)
diff --git a/drivers/regulator/lp8788-ldo.c b/drivers/regulator/lp8788-ldo.c
index cd5a14a..fcba90a 100644
--- a/drivers/regulator/lp8788-ldo.c
+++ b/drivers/regulator/lp8788-ldo.c
@@ -184,40 +184,6 @@ static enum lp8788_ldo_id lp8788_aldo_id[] = {
ALDO10,
};
-static int lp8788_ldo_enable(struct regulator_dev *rdev)
-{
- struct lp8788_ldo *ldo = rdev_get_drvdata(rdev);
-
- if (ldo->en_pin) {
- gpio_set_value(ldo->en_pin->gpio, ENABLE);
- return 0;
- } else {
- return regulator_enable_regmap(rdev);
- }
-}
-
-static int lp8788_ldo_disable(struct regulator_dev *rdev)
-{
- struct lp8788_ldo *ldo = rdev_get_drvdata(rdev);
-
- if (ldo->en_pin) {
- gpio_set_value(ldo->en_pin->gpio, DISABLE);
- return 0;
- } else {
- return regulator_disable_regmap(rdev);
- }
-}
-
-static int lp8788_ldo_is_enabled(struct regulator_dev *rdev)
-{
- struct lp8788_ldo *ldo = rdev_get_drvdata(rdev);
-
- if (ldo->en_pin)
- return gpio_get_value(ldo->en_pin->gpio) ? 1 : 0;
- else
- return regulator_is_enabled_regmap(rdev);
-}
-
static int lp8788_ldo_enable_time(struct regulator_dev *rdev)
{
struct lp8788_ldo *ldo = rdev_get_drvdata(rdev);
@@ -253,17 +219,17 @@ static struct regulator_ops lp8788_ldo_voltage_table_ops
= {
.list_voltage = regulator_list_voltage_table,
.set_voltage_sel = regulator_set_voltage_sel_regmap,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
- .enable = lp8788_ldo_enable,
- .disable = lp8788_ldo_disable,
- .is_enabled = lp8788_ldo_is_enabled,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
.enable_time = lp8788_ldo_enable_time,
};
static struct regulator_ops lp8788_ldo_voltage_fixed_ops = {
.get_voltage = lp8788_ldo_fixed_get_voltage,
- .enable = lp8788_ldo_enable,
- .disable = lp8788_ldo_disable,
- .is_enabled = lp8788_ldo_is_enabled,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
.enable_time = lp8788_ldo_enable_time,
};
@@ -535,43 +501,10 @@ static struct regulator_desc lp8788_aldo_desc[] = {
},
};
-static int lp8788_gpio_request_ldo_en(struct platform_device *pdev,
- struct lp8788_ldo *ldo,
- enum lp8788_ext_ldo_en_id id)
-{
- struct device *dev = >dev;
- struct lp8788_ldo_enable_pin *pin = ldo->en_pin;
- int ret, gpio, pinstate;
- char *name[] = {
- [EN_ALDO1] = "LP8788_EN_ALDO1",
- [EN_ALDO234] = "LP8788_EN_ALDO234",
- [EN_ALDO5] = "LP8788_EN_ALDO5",
- [EN_ALDO7] = "LP8788_EN_ALDO7",
- [EN_DLDO7] = "LP8788_EN_DLDO7",
- [EN_DLDO911] = "LP8788_EN_DLDO911",
- };
-
- gpio = pin->gpio;
- if (!gpio_is_valid(gpio)) {
- dev_err(dev, "invalid gpio: %d\n", gpio);
- return -EINVAL;
- }
-
- pinstate = pin->init_state;
- ret = devm_gpio_request_one(dev, gpio, pinstate, name[id]);
- if (ret == -EBUSY) {
- dev_warn(dev, "gpio%d already used\n", gpio);
- return 0;
- }
-
- return ret;
-}
-
static int lp8788_config_ldo_enable_mode(struct platform_device *pdev,
struct lp8788_ldo *ldo,
enum lp8788_ldo_id id)
{
- int ret;
struct lp8788 *lp = ldo->lp;
struct lp8788_platform_data *pdata = lp->pdata;
enum lp8788_ext_ldo_en_id enable_id;
@@ -613,14 +546,7 @@ static int lp8788_config_ldo_enable_mode(struct
platform_device *pdev,
goto set_default_ldo_enable_mode;
ldo->en_pin = pdata->ldo_pin[enable_id];
-
- ret = lp8788_gpio_request_ldo_en(pdev, ldo, enable_id);
- if (ret) {
- ldo->en_pin = NULL;
- goto set_default_ldo_enable_mode;
- }
-
- return ret;
+ return 0;
set_default_ldo_enable_mode:
return lp8788_update_bits(lp, LP8788_EN_SEL, en_mask[enable_id], 0);
@@ -644,6 +570,11 @@ static int lp8788_dldo_probe(struct platform_device *pdev)
if (ret)
return ret;
+ if (ldo->en_pin) {
+
[PATCH v3 1/4] regulator: core: support shared enable GPIO concept
A Regulator can be enabled by external GPIO pin.
This is configurable in the regulator_config.
At this moment, the GPIO can be owned by only one regulator device.
In some devices, multiple regulators are enabled by shared one GPIO pin.
This patch extends this limitation, enabling shared enable GPIO of regulators.
New list for enable GPIO: 'regulator_ena_gpio_list'
This manages enable GPIO list.
New structure for supporting shared enable GPIO: 'regulator_enable_gpio'
The enable count is used for balancing GPIO control count.
This count is incremented when GPIO is enabled.
On the other hand, it's decremented when GPIO is disabled.
Reference count: 'request_count'
The reference count, 'request_count' is incremented/decremented on
requesting/freeing the GPIO. This count makes sure only free the GPIO
when it has no users.
How it works
If the GPIO is already used, skip requesting new GPIO usage.
The GPIO is new one, request GPIO function and add it to the list of
enable GPIO.
This list is used for balancing enable GPIO count and pin control.
Updating a GPIO and invert code moved
'ena_gpio' and 'ena_gpio_invert' of the regulator_config were moved to
new function, regulator_ena_gpio_request().
Use regulator_enable_pin structure rather than regulator_dev.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/core.c | 86 +-
include/linux/regulator/driver.h |2 +
2 files changed, 78 insertions(+), 10 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index da9782b..71d6adc 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -51,6 +51,7 @@
static DEFINE_MUTEX(regulator_list_mutex);
static LIST_HEAD(regulator_list);
static LIST_HEAD(regulator_map_list);
+static LIST_HEAD(regulator_ena_gpio_list);
static bool has_full_constraints;
static bool board_wants_dummy_regulator;
@@ -69,6 +70,19 @@ struct regulator_map {
};
/*
+ * struct regulator_enable_gpio
+ *
+ * Management for shared enable GPIO pin
+ */
+struct regulator_enable_gpio {
+ struct list_head list;
+ int gpio;
+ u32 enable_count; /* a number of enabled shared GPIO */
+ u32 request_count; /* a number of requested shared GPIO */
+ unsigned int ena_gpio_invert:1;
+};
+
+/*
* struct regulator
*
* One for each consumer device.
@@ -1456,6 +1470,65 @@ void devm_regulator_put(struct regulator *regulator)
}
EXPORT_SYMBOL_GPL(devm_regulator_put);
+/* Manage enable GPIO list. Same GPIO pin can be shared among regulators */
+static int regulator_ena_gpio_request(struct regulator_dev *rdev,
+ const struct regulator_config *config)
+{
+ struct regulator_enable_gpio *pin;
+ int ret;
+
+ list_for_each_entry(pin, _ena_gpio_list, list) {
+ if (pin->gpio == config->ena_gpio) {
+ rdev_dbg(rdev, "GPIO %d is already used\n",
+ config->ena_gpio);
+ goto update_ena_gpio_to_rdev;
+ }
+ }
+
+ ret = gpio_request_one(config->ena_gpio,
+ GPIOF_DIR_OUT | config->ena_gpio_flags,
+ rdev_get_name(rdev));
+ if (ret)
+ return ret;
+
+ pin = kzalloc(sizeof(struct regulator_enable_gpio), GFP_KERNEL);
+ if (pin == NULL) {
+ gpio_free(config->ena_gpio);
+ return -ENOMEM;
+ }
+
+ pin->gpio = config->ena_gpio;
+ pin->ena_gpio_invert = config->ena_gpio_invert;
+ list_add(>list, _ena_gpio_list);
+
+update_ena_gpio_to_rdev:
+ pin->request_count++;
+ rdev->ena_pin = pin;
+ return 0;
+}
+
+static void regulator_ena_gpio_free(struct regulator_dev *rdev)
+{
+ struct regulator_enable_gpio *pin, *n;
+
+ if (!rdev->ena_pin)
+ return;
+
+ /* Free the GPIO only in case of no use */
+ list_for_each_entry_safe(pin, n, _ena_gpio_list, list) {
+ if (pin->gpio == rdev->ena_pin->gpio) {
+ if (pin->request_count <= 1) {
+ pin->request_count = 0;
+ gpio_free(pin->gpio);
+ list_del(>list);
+ kfree(pin);
+ } else {
+ pin->request_count--;
+ }
+ }
+ }
+}
+
static int _regulator_do_enable(struct regulator_dev *rdev)
{
int ret, delay;
@@ -3435,18 +3508,13 @@ regulator_register(const struct regulator_desc
*regulator_desc,
dev_set_drvdata(>dev, rdev);
if (config->ena_gpio && gpio_is_valid(config->ena_gpio)) {
- ret = gpio_request_one(config->ena_gpio,
- GPIOF_DIR_OUT | config->ena_gpio_flags,
-
[PATCH v3 0/4] regulator: core: support shared enable GPIO
A Regulator can be enabled by external GPIO pin which is configurable in the regulator_config. At this moment, the GPIO can be owned by only one regulator device. In some devices like LP8788 LDOs, multiple regulators are enabled by shared one GPIO pin. This patch-set enables shared enable GPIO concept and fix LP8788 LDO driver as well. Patches were generated based on 'for-next' of regulator.git (git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git) Patch v3. a) Add a reference count, 'request_count' which makes sure only free the GPIO when it has no users b) Make return type of regulator_ena_gpio_ctrl() c) Free the GPIO when kzalloc() gets failed in regulator_ena_gpio_request() d) Add a pointer to the GPIO structure to the regulator_dev on setting the GPIO : use a GPIO structure directly instead of scanning the GPIO list Patch v2. a) Add a list for enable GPIO b) Add a reference count, 'enable_count' for actual pin control Patch v1. Initial patch Milo(Woogyom) Kim (4): regulator: core: support shared enable GPIO concept regulator: core: manage enable GPIO list regulator: core: use regulator_ena_pin member regulator: lp8788-ldo: use ena_pin of regulator-core for external control drivers/regulator/core.c | 142 +- drivers/regulator/lp8788-ldo.c | 98 +- include/linux/regulator/driver.h |4 +- 3 files changed, 142 insertions(+), 102 deletions(-) -- 1.7.9.5 Best Regards, Milo -- 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: manual merge of the tip tree with the kbuild tree
That is the right fix indeed.
Stephen Rothwell wrote:
>Hi all,
>
>Today's linux-next merge of the tip tree got a conflict in
>kernel/timeconst.pl between commit 70730bca1331 ("kernel: Replace
>timeconst.pl with a bc script") from the kbuild tree and commit
>63a3f603413f ("timeconst.pl: Eliminate Perl warning") from the tip
>tree.
>
>I just droppped the tip tree version (I deleted the file) and can carry
>the fix as necessary (no action is required).
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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/
[RFC 2/8] ARM: twd: register clock event for 1 core SMP
Register percpu local timer for scheduler tick in the case of one core SMP configuration. In other cases - secondary cpu's as well as boot cpu's having more than one core, this is being registered as per existing boot flow, with a difference that they happens after delay calibration. Registering the clock for tick in case of one core should be done before Kernel calibrates delay (this is required to boot, unless local timer is the only one registered for tick). Registering twd local timer at init_time (which platforms are doing now) helps achieve that with the proposed change. This helps in an almost booting Kernel (minimal) by only relying on ARM parts for an A9 one core SMP. Signed-off-by: Afzal Mohammed --- arch/arm/kernel/smp_twd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c index 616268c..118f4f2 100644 --- a/arch/arm/kernel/smp_twd.c +++ b/arch/arm/kernel/smp_twd.c @@ -335,6 +335,9 @@ static int __init twd_local_timer_common_register(struct device_node *np) twd_get_clock(np); + if (num_possible_cpus() == 1) + twd_timer_setup(evt); + return 0; out_irq: -- 1.7.12 -- 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/
[RFC 6/8] ARM: OMAP2+: am43: basic dt support
Describe minimal DT boot machine details for AM43 based SoC's. AM43
family of SoC's are ARM Cortex-A9 based with one core in SMP
configuration. Low level debug could be achieved by selecting
DEBUG_AM33XXUART1. To boot AM43 SoC, this change is sufficient w.r.t
Kernel (considering the fact that strictly speaking DT sources does
not classify as a part of Kernel). Here private timer of the one and
only core is being used as clock event (as well as, as time source).
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/board-generic.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 0274ff7..e083f08 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,7 +15,10 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include "common.h"
@@ -182,3 +185,18 @@ DT_MACHINE_START(OMAP5_DT, "Generic OMAP5 (Flattened
Device Tree)")
.restart= omap44xx_restart,
MACHINE_END
#endif
+
+#ifdef CONFIG_SOC_AM43
+static const char *am43_boards_compat[] __initdata = {
+ "ti,am43",
+ NULL,
+};
+
+DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device Tree)")
+ .map_io = debug_ll_io_init,
+ .init_irq = irqchip_init,
+ .init_machine = omap_generic_init,
+ .init_time = twd_local_timer_of_register,
+ .dt_compat = am43_boards_compat,
+MACHINE_END
+#endif
--
1.7.12
--
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/
[RFC 7/8] ARM: dts: am4372: initial support
DT source (minimal) for AM4372 SoC. Those represented here are the
minimal DT nodes necessary to get kernel booting.
Signed-off-by: Afzal Mohammed
---
arch/arm/boot/dts/am4372.dtsi | 55 +++
1 file changed, 55 insertions(+)
create mode 100644 arch/arm/boot/dts/am4372.dtsi
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
new file mode 100644
index 000..178c41f
--- /dev/null
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -0,0 +1,55 @@
+/*
+ * Device Tree Source for AM4372 SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "ti,am4372", "ti,am43";
+ interrupt-parent = <>;
+
+
+ aliases {
+ serial0 =
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = "arm,cortex-a9";
+ };
+ };
+
+ gic: interrupt-controller@48241000 {
+ compatible = "arm,cortex-a9-gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x48241000 0x1000>,
+ <0x48240100 0x0100>;
+ };
+
+ twd1: local-timer@0x48240600 {
+ compatible = "arm,cortex-a9-twd-timer";
+ reg = <0x48240600 0x20>;
+ interrupts = <1 13 0x304>;
+ };
+
+ ocp {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ uart1: serial@44e09000 {
+ compatible = "ti,am4372-uart","ti,omap2-uart";
+ clock-frequency = <4800>;
+ reg = <0x44e09000 0x2000>;
+ interrupts = <0 72 0x4>;
+ };
+ };
+};
--
1.7.12
--
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/
[RFC 3/8] ARM: twd: clock rate from DT (if no DT clk tree)
Add an optional property to find clock-frequency from DT. This helps
as a fallback mechanism in case there is no representation of clock
tree in DT.
Signed-off-by: Afzal Mohammed
---
Documentation/devicetree/bindings/arm/twd.txt | 7 ++-
arch/arm/kernel/smp_twd.c | 8
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/twd.txt
b/Documentation/devicetree/bindings/arm/twd.txt
index 75b8610..fdafa4f 100644
--- a/Documentation/devicetree/bindings/arm/twd.txt
+++ b/Documentation/devicetree/bindings/arm/twd.txt
@@ -7,8 +7,9 @@ and watchdog.
The TWD is usually attached to a GIC to deliver its two per-processor
interrupts.
-** Timer node required properties:
+** Timer node properties:
+Required properties:
- compatible : Should be one of:
"arm,cortex-a9-twd-timer"
"arm,cortex-a5-twd-timer"
@@ -19,12 +20,16 @@ interrupts.
- reg : Specify the base address and the size of the TWD timer
register window.
+Optional property:
+- clock-frequency : frequency(Hz) of peripheral clock fed to timer
+
Example:
twd-timer@2c000600 {
compatible = "arm,arm11mp-twd-timer"";
reg = <0x2c000600 0x20>;
interrupts = <1 13 0xf01>;
+ clock-frequency = <3>;
};
** Watchdog node properties:
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index 118f4f2..aac0f9f 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -247,7 +247,15 @@ static void twd_get_clock(struct device_node *np)
twd_clk = clk_get_sys("smp_twd", NULL);
if (IS_ERR(twd_clk)) {
+ u32 freq;
+
pr_err("smp_twd: clock not found %d\n", (int) PTR_ERR(twd_clk));
+
+ /* If there is no representation of clock tree in DT,
+ provide a fallback option to obtain frequency
+*/
+ if (np && !of_property_read_u32(np, "clock-frequency", ))
+ twd_timer_rate = freq;
return;
}
--
1.7.12
--
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/
[RFC 8/8] ARM: dts: am43-pre-silicon support
AM43 SoC is in pre-silicon stage, meanwhile it has been modelled in
a pre-silicon platform. To validate and boot Linux in pre-silicon
platform that emulates an AM43 SoC, add DT build support.
As bootloader is not used, bootargs is passed through DT.
Note: This would be replaced by an original board support.
Signed-off-by: Afzal Mohammed
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/am43-pre-silicon.dts | 31 +++
2 files changed, 33 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/am43-pre-silicon.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 94d88b9..b434344 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -124,7 +124,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap5-evm.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
- am335x-bone.dtb
+ am335x-bone.dtb \
+ am43-pre-silicon.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/am43-pre-silicon.dts
b/arch/arm/boot/dts/am43-pre-silicon.dts
new file mode 100644
index 000..b9c6297
--- /dev/null
+++ b/arch/arm/boot/dts/am43-pre-silicon.dts
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* AM43 Pre Silicon */
+
+/dts-v1/;
+
+/include/ "am4372.dtsi"
+
+/ {
+ model = "TI AM43 Pre Silicon";
+ compatible = "ti,am43-pre-silicon","ti,am4372","ti,am43";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+
+ chosen {
+ bootargs = "console=ttyO0,115200n8 root=/dev/ram rw
initrd=0x8200,32MB earlyprintk";
+ };
+};
+
+ {
+ clock-frequency = <3>;
+};
--
1.7.12
--
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/
[RFC 5/8] ARM: OMAP2+: am43: Kconfig
Add Kconfig option for AM43 family of SoC's, these are ARM Cortex A9 based (SMP configuration with 1 core). Signed-off-by: Afzal Mohammed --- arch/arm/mach-omap2/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 49ac3df..683fbaa 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -141,6 +141,17 @@ config SOC_AM33XX select MULTI_IRQ_HANDLER select COMMON_CLK +config SOC_AM43 + bool "TI AM43" + depends on ARCH_OMAP2PLUS + default y + select CPU_V7 + select HAVE_SMP + select LOCAL_TIMERS if SMP + select MULTI_IRQ_HANDLER + select ARM_GIC + select COMMON_CLK + config OMAP_PACKAGE_ZAF bool -- 1.7.12 -- 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/
[RFC 4/8] ARM: am33xx: ll debug config help
Selecting DEBUG_AM33XXUART1 routes low level debug messages to first UART instance of AM335x based SoC's. This selection is valid for upcoming AM43 based SoC's too. Make this information available upon configuring. Signed-off-by: Afzal Mohammed --- arch/arm/Kconfig.debug | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index aca..b717b78 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -542,6 +542,9 @@ choice config DEBUG_AM33XXUART1 bool "AM33XX UART1" + help + Route low level debug messages to first uart instance + for boards based on am335 and am43 family of SoC's config DEBUG_ZOOM_UART bool "Zoom2/3 UART" -- 1.7.12 -- 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/
[RFC 1/8] ARM: localtimer: return percpu clkevt on register
Return percpu clock event on local timer register. It is the boot cpu
that calls this and it can use the returned percpu clock event to
register a clock event in the case of SMP configuration with one core.
This helps to have a booting Kernel even if no other timer is
registered for clock tick.
Signed-off-by: Afzal Mohammed
---
arch/arm/include/asm/localtimer.h | 7 ---
arch/arm/kernel/smp.c | 8
arch/arm/kernel/smp_twd.c | 5 +++--
3 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/arm/include/asm/localtimer.h
b/arch/arm/include/asm/localtimer.h
index f77ffc1..c3f89c0 100644
--- a/arch/arm/include/asm/localtimer.h
+++ b/arch/arm/include/asm/localtimer.h
@@ -23,11 +23,12 @@ struct local_timer_ops {
/*
* Register a local timer driver
*/
-int local_timer_register(struct local_timer_ops *);
+struct clock_event_device *local_timer_register(struct local_timer_ops *);
#else
-static inline int local_timer_register(struct local_timer_ops *ops)
+static inline
+struct clock_event_device *local_timer_register(struct local_timer_ops *ops)
{
- return -ENXIO;
+ return ERR_PTR(-ENXIO);
}
#endif
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 5f73f70..42d95d6 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -491,16 +491,16 @@ static void __cpuinit broadcast_timer_setup(struct
clock_event_device *evt)
static struct local_timer_ops *lt_ops;
#ifdef CONFIG_LOCAL_TIMERS
-int local_timer_register(struct local_timer_ops *ops)
+struct clock_event_device *local_timer_register(struct local_timer_ops *ops)
{
if (!is_smp() || !setup_max_cpus)
- return -ENXIO;
+ return ERR_PTR(-ENXIO);
if (lt_ops)
- return -EBUSY;
+ return ERR_PTR(-EBUSY);
lt_ops = ops;
- return 0;
+ return _cpu(percpu_clockevent, smp_processor_id());
}
#endif
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index c092115..616268c 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -315,6 +315,7 @@ static struct local_timer_ops twd_lt_ops __cpuinitdata = {
static int __init twd_local_timer_common_register(struct device_node *np)
{
int err;
+ struct clock_event_device *evt;
twd_evt = alloc_percpu(struct clock_event_device *);
if (!twd_evt) {
@@ -328,8 +329,8 @@ static int __init twd_local_timer_common_register(struct
device_node *np)
goto out_free;
}
- err = local_timer_register(_lt_ops);
- if (err)
+ evt = local_timer_register(_lt_ops);
+ if (IS_ERR(evt))
goto out_irq;
twd_get_clock(np);
--
1.7.12
--
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/
[RFC 0/8] ARM: AM43 (OMAP2+) boot support
Hi, This series adds minimal support to boot Linux on platforms having AM43 based SoC's. This is being sent as an RFC to seek opinion about modification in twd to register percpu local timer clock event for scheduler tick in the case of one core SMP. AM43 SoC's are based on ARM Cortex-A9. It is an ARM Cortex-A9 SMP configuration with one core (not uniprocessor configuration). AM43 is similar to AM335x in it's peripheral capabilities, with many of the peripheral register mapping's similar like that of uart. AM43 is in pre-silicon stage and currently there are no public documents. This series has been tested on a pre-silicon platform that emulates AM43 SoC, changes proposed here are minimal - to get it booting. Kernel was directly run without the help of bootloader - Images were directly loaded onto a pre-initialized RAM and ARM registers updated as required for booting. Changes have been made over linux-next (next-20130213) with three "OF" related reverts (which otherwise causes problem in other platforms also) and compiled with omap2plus_defconfig. Multiplatform option was enabled, while most of CONFIG options were deselected for a faster boot. Beagle bone boots as earlier with these changes. An interesting observation is that it may be possible to boot this platform to console without any platform specific modification to proper Kernel (by that I mean excluding DT sources) using Arnd's, "[PATCH,RFC] default machine descriptor for multiplatform", along with a "CLOCKSOURCE_OF_DECLARE" for smp twd. But later on to make SoC do any really useful work or to get done things that the SoC is meant to do, platform changes like omap-hwmod, handling power management, clock tree, detecting SoC capabilities etc would have to be made, necessitating DT_MACHINE_START at least in the foreseeable future. Patch - 8 that makes AM43 boot on pre-silicon platform would be replaced later by a one for original board. Last but not least, thanks to Ankur Kishore (who first made Linux to boot on AM43) for all the help that made Linux bringup easier. Regards Afzal Afzal Mohammed (8): ARM: localtimer: return percpu clkevt on register ARM: twd: register clock event for 1 core SMP ARM: twd: clock rate from DT (if no DT clk tree) ARM: am33xx: ll debug config help ARM: OMAP2+: am43: Kconfig ARM: OMAP2+: am43: basic dt support ARM: dts: am4372: initial support ARM: dts: am43-pre-silicon support Documentation/devicetree/bindings/arm/twd.txt | 7 +++- arch/arm/Kconfig.debug| 3 ++ arch/arm/boot/dts/Makefile| 3 +- arch/arm/boot/dts/am43-pre-silicon.dts| 31 +++ arch/arm/boot/dts/am4372.dtsi | 55 +++ arch/arm/include/asm/localtimer.h | 7 ++-- arch/arm/kernel/smp.c | 8 ++-- arch/arm/kernel/smp_twd.c | 16 +++- arch/arm/mach-omap2/Kconfig | 11 ++ arch/arm/mach-omap2/board-generic.c | 18 + 10 files changed, 148 insertions(+), 11 deletions(-) create mode 100644 arch/arm/boot/dts/am43-pre-silicon.dts create mode 100644 arch/arm/boot/dts/am4372.dtsi -- 1.7.12 -- 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] mm: break circular include from linux/mmzone.h
linux/mmzone.h included linux/memory_hotplug.h, and linux/memory_hotplug.h also included linux/mmzone.h, so there's a bad cirlular. these are quite mechanical changes by a simple script, I've tested for ARCH x86,arm,mips, may someone help to test more. Signed-off-by: liguang --- many thanks to Fengguang Wu and Stephen Rothwell who find build errors for v1, and also David Rientjes who try to fix v1. I'm really regretful for the bold v1 which lack of consideration and test. arch/alpha/include/asm/pgalloc.h |1 + arch/alpha/include/asm/pgtable.h |1 + arch/avr32/mm/init.c |1 + arch/cris/arch-v10/mm/init.c |1 + arch/cris/arch-v32/mm/init.c |1 + arch/hexagon/kernel/setup.c |1 + arch/ia64/kernel/acpi.c |1 + arch/ia64/kernel/machine_kexec.c |1 + arch/ia64/mm/init.c |1 + arch/ia64/sn/kernel/setup.c |1 + arch/ia64/sn/kernel/sn2/sn2_smp.c |1 + arch/m32r/mm/discontig.c |1 + arch/m68k/include/asm/virtconvert.h |1 + arch/mips/include/asm/pgtable.h |1 + arch/mips/include/asm/sn/mapped_kernel.h |1 + arch/mips/sgi-ip27/ip27-hubio.c |1 + arch/mips/sgi-ip27/ip27-klnuma.c |1 + arch/mips/sgi-ip27/ip27-memory.c |1 + arch/mips/sgi-ip27/ip27-nmi.c |1 + arch/mips/sgi-ip27/ip27-reset.c |1 + arch/powerpc/mm/numa.c|1 + arch/powerpc/platforms/ps3/spu.c |1 + arch/sh/kernel/setup.c|1 + arch/sparc/mm/init_64.c |1 + arch/tile/gxio/kiorpc.c |1 + arch/tile/include/asm/pgalloc.h |1 + arch/tile/kernel/pci_gx.c |1 + arch/tile/kernel/setup.c |1 + arch/tile/kernel/stack.c |1 + arch/x86/kernel/acpi/srat.c |1 + arch/x86/kernel/aperture_64.c |1 + arch/x86/kernel/apic/numaq_32.c |1 + arch/x86/kernel/probe_roms.c |1 + arch/x86/kernel/setup.c |1 + arch/x86/kernel/topology.c|1 + arch/x86/mm/numa.c|1 + drivers/char/agp/amd64-agp.c |1 + drivers/edac/amd64_edac.h |1 + drivers/edac/i5100_edac.c |1 + drivers/edac/i5400_edac.c |1 + drivers/edac/i7300_edac.c |1 + drivers/edac/i7core_edac.c|1 + drivers/edac/sb_edac.c|1 + drivers/s390/char/sclp_cmd.c |1 + drivers/staging/tidspbridge/core/tiomap3430.c |1 + drivers/video/vermilion/vermilion.c |1 + fs/file.c |1 + fs/proc/meminfo.c |1 + fs/proc/nommu.c |1 + fs/proc/page.c|1 + include/linux/bootmem.h |1 + include/linux/gfp.h |1 + include/linux/memory_hotplug.h|1 - include/linux/mempolicy.h |1 + include/linux/mm.h|1 + include/linux/mmzone.h|2 -- include/linux/swap.h |1 + include/linux/topology.h |1 + include/linux/vmstat.h|1 + mm/kmemleak.c |1 + mm/mlock.c|1 + mm/mmzone.c |1 + mm/page_cgroup.c |1 + mm/quicklist.c|1 + mm/sparse-vmemmap.c |1 + mm/sparse.c |1 + 66 files changed, 64 insertions(+), 3 deletions(-) diff --git a/arch/alpha/include/asm/pgalloc.h b/arch/alpha/include/asm/pgalloc.h index bc2a0da..ab9c10e 100644 --- a/arch/alpha/include/asm/pgalloc.h +++ b/arch/alpha/include/asm/pgalloc.h @@ -3,6 +3,7 @@ #include #include +#include /* * Allocate and free page tables. The xxx_kernel() versions are diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h index 81a4342..def3f86 100644 --- a/arch/alpha/include/asm/pgtable.h +++ b/arch/alpha/include/asm/pgtable.h @@ -11,6 +11,7 @@ * in (currently 8192). */ #include +#include #include #include /* For TASK_SIZE */ diff --git a/arch/avr32/mm/init.c b/arch/avr32/mm/init.c index 2798c2d..d613273 100644 --- a/arch/avr32/mm/init.c +++
RE: Getting rid of freezer for suspend [was Re: [fuse-devel] [PATCH] fuse: make fuse daemon frozen along with kernel threads]
> -Original Message- > From: Rafael J. Wysocki [mailto:r...@sisk.pl] > Sent: Friday, February 15, 2013 1:38 AM > To: Miklos Szeredi > Cc: Pavel Machek; Goswin von Brederlow; Li, Fei; Brown, Len; > mi...@redhat.com; pet...@infradead.org; Wang, Biao; > linux...@vger.kernel.org; fuse-de...@lists.sourceforge.net; > linux-kernel@vger.kernel.org; Liu, Chuansheng > Subject: Re: Getting rid of freezer for suspend [was Re: [fuse-devel] [PATCH] > fuse: > make fuse daemon frozen along with kernel threads] > > On Thursday, February 14, 2013 02:09:50 PM Miklos Szeredi wrote: > > On Thu, Feb 14, 2013 at 1:11 PM, Rafael J. Wysocki wrote: > > > On Thursday, February 14, 2013 11:41:16 AM Miklos Szeredi wrote: > > > > >> > > >> It is essentially the same mechanism that is used to delay the > > >> freezing of kernel threads after userspace tasks have been frozen. > > >> Except it's a lot more difficult to determine which userspace tasks > > >> need to be suspended late and which aren't. > > > > > > Well, I suppose that information is available to user space. > > > > > > Do we need an interface for a process to mark itself as PF_FREEZE_LATE or > > > do we need an interface for one process to mark another process as > > > PF_FREEZE_LATE, or both? > > > > As a first step marking self with PF_FREEZE_LATE and inheriting this > > flag across fork/clone would work for most cases, I think. > > OK, so we can just have a switch for that in /proc I suppose. Thanks for feedback and suggestion. We have ever tried similar idea, expose interface /sys/power/pm_freeze_daemon, userspace tasks write 1 to this attribute to make itself to be frozen at the same time with kernel tasks, and it worked in our experiment. Do you think it's suitable and enough to use such attribute /sys/power/pm_freeze_late, or other more suitable place under /proc suggested? If needed, I can prepare the patch. Best Regards, Li Fei > > Marking an unrelated process would have all sorts of issues: Who has > > permission to do this? Won't it be misused to "fix" random freezer > > issues. > > Yes, that's why I was asking. > > Thanks, > Rafael > > > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center.
Re: kswapd craziness round 2
On Monday, 18 February 2013 06:10:02 UTC+8, Jiri Slaby wrote:
> Hi,
>
> You still feel the sour taste of the "kswapd craziness in v3.7" thread,
> right? Welcome to the hell, part two :{.
>
> I believe this started happening after update from
> 3.8.0-rc4-next-20130125 to 3.8.0-rc7-next-20130211. The same as before,
> many hours of uptime are needed and perhaps some suspend/resume cycles
> too. Memory pressure is not high, plenty of I/O cache:
> # free
> total used free sharedbuffers cached
> Mem: 60266925571184 455508 0 3512522016648
> -/+ buffers/cache:32032842823408
> Swap:0 0 0
>
> kswap is working very toughly though:
> root 580 0.6 0.0 0 0 ?Súno12 46:21
[kswapd0]
>
> This happens on I/O activity right now. For example by updatedb or find
> /. This is what the stack trace of kswapd0 looks like:
> [] shrink_slab+0xa1/0x2d0
> [] kswapd+0x541/0x930
> [] kthread+0xc0/0xd0
> [] ret_from_fork+0x7c/0xb0
> [] 0x
Likewise with 3.8-rc, I've been able to reproduce [1] a livelock
scenario which hoses the box and observe RCU stalls are observed [2].
There may be a connection; I'll do a bit more debugging in the next few
days.
Daniel
--- [1]
1. live-booted image using ramdisk
2. boot 3.8-rc with <16GB memory and without swap
3. run OpenMP NAS Parallel Benchmark dc.B against local disk (ie not
ramdisk)
4. observe hang O(30) mins later
--- [2]
[ 2675.587878] INFO: rcu_sched self-detected stall on CPU { 5} (t=24000
jiffies g=6313 c=6312 q=68)
--
Daniel J Blueman
Principal Software Engineer, Numascale Asia
--
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] net: fix functions and variables related to netns_ipvs->sysctl_sync_qlen_max
于 2013年02月16日 05:39, Julian Anastasov 写道: > > Hello, > > On Thu, 14 Feb 2013, Andrew Morton wrote: > >> On Thu, 7 Feb 2013 10:40:26 +0200 (EET) >> Julian Anastasov wrote: >> Another question about the sysctl_sync_qlen_max: This variable is assigned as: ipvs->sysctl_sync_qlen_max = nr_free_buffer_pages() / 32; The function nr_free_buffer_pages actually means: counts of pages which are beyond high watermark within ZONE_DMA and ZONE_NORMAL. is it ok to be called here? Some people misused this function because the function name was misleading them. I am sorry I am totally not familiar with the ipvs code, so I am just asking you about this. >>> >>> Using nr_free_buffer_pages should be fine here. >>> We are using it as rough estimation for the number of sync >>> buffers we can use in NORMAL zones. We are using dev->mtu >>> for such buffers, so it can take a PAGE_SIZE for a buffer. >>> We are not interested in HIGHMEM size. high watermarks >>> should have negliable effect. I'm even not sure whether >>> we need to clamp it for systems with TBs of memory. >> >> Using nr_free_buffer_pages() is good-enough-for-now. There are >> questions around the name of this thing and its exact functionality and >> whether callers are using it appropriately. But if anything is changed >> there, it will be as part of kernel-wide sweep. >> >> One thing to bear in mind is memory hot[un]plug. Anything which was >> sized using nr_free_buffer_pages() (or similar) may become >> inappropriately sized if memory is added or removed. So any site which >> uses nr_free_buffer_pages() really should be associated with a hotplug >> handler and a great pile of code to resize the structure at runtime. >> It's pretty ugly stuff :( I suspect it usually Just Doesn't Matter. > > I'll try to think on this hotplug problem > and also on the si_meminfo usage in net/netfilter/ipvs/ip_vs_ctl.c > which is quite wrong for systems with HIGHMEM, may be > we need there a free+reclaimable+file function for > NORMAL zone. > >> Redarding this patch: >> net-change-type-of-netns_ipvs-sysctl_sync_qlen_max.patch and >> net-fix-functions-and-variables-related-to-netns_ipvs-sysctl_sync_qlen_max.patch >> are joined at the hip and should be redone as a single patch with a >> suitable changelog, please. And with a cc:net...@vger.kernel.org. > > Agreed, Zhang Yanfei and Simon? I'm just not sure, > may be this combined patch should hit only the > ipvs->nf->net trees? Or may be net-next, if we don't have > time for 3.8. > Should I resend the combined patch? -- 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] iommu: making IOMMU sysfs nodes API public
On 13/02/13 04:15, Alex Williamson wrote:
On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
On 12/02/13 16:07, Alex Williamson wrote:
On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
Having this patch in a tree, adding new nodes in sysfs
for IOMMU groups is going to be easier.
The first candidate for this change is a "dma-window-size"
property which tells a size of a DMA window of the specific
IOMMU group which can be used later for locked pages accounting.
I'm still churning on this one; I'm nervous this would basically creat
a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
iommu driver can add random attributes. That can get ugly for
userspace.
Is not it exactly what sysfs is for (unlike /proc)? :)
Um, I hope it's a little more thought out than /proc.
On the other hand, for the application of userspace knowing how much
memory to lock for vfio use of a group, it's an appealing location to
get that information. Something like libvirt would already be poking
around here to figure out which devices to bind. Page limits need to be
setup prior to use through vfio, so sysfs is more convenient than
through vfio ioctls.
True. DMA window properties do not change since boot so sysfs is the right
place to expose them.
But then is dma-window-size just a vfio requirement leaking over into
iommu groups? Can we allow iommu driver based attributes without giving
up control of the namespace? Thanks,
Who are you asking these questions? :)
Anyone, including you. Rather than dropping misc files in sysfs to
describe things about the group, I think the better solution in your
case might be a link from the group to an existing sysfs directory
describing the PE. I believe your PE is rooted in a PCI bridge, so that
presumably already has a representation in sysfs. Can the aperture size
be determined from something in sysfs for that bridge already? I'm just
not ready to create a grab bag of sysfs entries for a group yet.
Thanks,
At the moment there is no information neither in sysfs nor
/proc/device-tree about the dma-window. And adding a sysfs entry per PE
(powerpc partitionable end-point which is often a PHB but not always) just
for VFIO is quite heavy.
We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
"dma-window" property there. And replace it with a symlink when and if we
add something for PE later. Would work?
Alex
Signed-off-by: Alexey Kardashevskiy
---
drivers/iommu/iommu.c | 19 ++-
include/linux/iommu.h | 20
2 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index b0afd3d..58cc298 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -52,22 +52,6 @@ struct iommu_device {
char *name;
};
-struct iommu_group_attribute {
- struct attribute attr;
- ssize_t (*show)(struct iommu_group *group, char *buf);
- ssize_t (*store)(struct iommu_group *group,
-const char *buf, size_t count);
-};
-
-#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store) \
-struct iommu_group_attribute iommu_group_attr_##_name =\
- __ATTR(_name, _mode, _show, _store)
-
-#define to_iommu_group_attr(_attr) \
- container_of(_attr, struct iommu_group_attribute, attr)
-#define to_iommu_group(_kobj) \
- container_of(_kobj, struct iommu_group, kobj)
-
static ssize_t iommu_group_attr_show(struct kobject *kobj,
struct attribute *__attr, char *buf)
{
@@ -98,11 +82,12 @@ static const struct sysfs_ops iommu_group_sysfs_ops = {
.store = iommu_group_attr_store,
};
-static int iommu_group_create_file(struct iommu_group *group,
+int iommu_group_create_file(struct iommu_group *group,
struct iommu_group_attribute *attr)
{
return sysfs_create_file(>kobj, >attr);
}
+EXPORT_SYMBOL_GPL(iommu_group_create_file);
static void iommu_group_remove_file(struct iommu_group *group,
struct iommu_group_attribute *attr)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index f3b99e1..6d24ba7 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -21,6 +21,7 @@
#include
#include
+#include
#define IOMMU_READ (1)
#define IOMMU_WRITE (2)
@@ -197,6 +198,25 @@ static inline int report_iommu_fault(struct iommu_domain
*domain,
return ret;
}
+struct iommu_group_attribute {
+ struct attribute attr;
+ ssize_t (*show)(struct iommu_group *group, char *buf);
+ ssize_t (*store)(struct iommu_group *group,
+const char *buf, size_t count);
+};
+
+#define IOMMU_GROUP_ATTR(_name, _mode, _show, _store) \
+struct iommu_group_attribute iommu_group_attr_##_name =\
+ __ATTR(_name, _mode, _show, _store)
+
Re: [patch 1/2] mm: fincore()
Andrew Morton writes: > The syscall should handle the common usages very well. But it > shouldn't handle uncommon usages very badly! If the user is actually dealing with the contents of the file, following the established mincore is preferred, since it's in the noise anyway. Which comes back to needing a user; I'll see what I can come up with. Cheers, 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/
[PATCH] cgroup: fail if monitored file and event_control are in different cgroup
If we pass fd of memory.usage_in_bytes of cgroup A to cgroup.event_control
of cgroup B, then we won't get memory usage notification from A but B!
What's worse, if A and B are in different mount hierarchy, we'll end up
accessing NULL pointer!
Disallow this kind of invalid usage.
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 65c8101..a41673c 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -3911,6 +3911,7 @@ static int cgroup_write_event_control(struct cgroup
*cgrp, struct cftype *cft,
const char *buffer)
{
struct cgroup_event *event = NULL;
+ struct cgroup *cgrp_cfile;
unsigned int efd, cfd;
struct file *efile = NULL;
struct file *cfile = NULL;
@@ -3966,6 +3967,16 @@ static int cgroup_write_event_control(struct cgroup
*cgrp, struct cftype *cft,
goto fail;
}
+ /*
+* The file to be monitored must be in the same cgroup as
+* cgroup.event_control is.
+*/
+ cgrp_cfile = __d_cgrp(cfile->f_dentry->d_parent);
+ if (cgrp_cfile != cgrp) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
if (!event->cft->register_event || !event->cft->unregister_event) {
ret = -EINVAL;
goto fail;
--
1.8.0.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/
[PATCH v2] cgroup: fix cgroup_rmdir() vs close(eventfd) race
commit 205a872bd6f9a9a09ef035ef1e90185a8245cc58 ("cgroup: fix lockdep
warning for event_control") solved a deadlock by introducing a new
bug.
Move cgrp->event_list to a temporary list doesn't mean you can traverse
this list locklessly, because at the same time cgroup_event_wake() can
be called and remove the event from the list. The result of this race
is disastrous.
We adopt the way how kvm irqfd code implements race-free event removal,
which is now described in the comments in cgroup_event_wake().
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 50 ++
1 file changed, 34 insertions(+), 16 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 26c071c..65c8101 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -217,6 +217,10 @@ struct cgroup_event {
*/
struct list_head list;
/*
+* Need to notify userspace when this event is removed?
+*/
+ bool signal_on_remove;
+ /*
* All fields below needed to unregister event when
* userspace closes eventfd.
*/
@@ -3833,8 +3837,17 @@ static void cgroup_event_remove(struct work_struct *work)
remove);
struct cgroup *cgrp = event->cgrp;
+ remove_wait_queue(event->wqh, >wait);
+
event->cft->unregister_event(cgrp, event->cft, event->eventfd);
+ /*
+* If this event is to be removed due to cgroup removal,
+* we notify userspace.
+*/
+ if (event->signal_on_remove)
+ eventfd_signal(event->eventfd, 1);
+
eventfd_ctx_put(event->eventfd);
kfree(event);
dput(cgrp->dentry);
@@ -3854,15 +3867,25 @@ static int cgroup_event_wake(wait_queue_t *wait,
unsigned mode,
unsigned long flags = (unsigned long)key;
if (flags & POLLHUP) {
- __remove_wait_queue(event->wqh, >wait);
- spin_lock(>event_list_lock);
- list_del_init(>list);
- spin_unlock(>event_list_lock);
/*
-* We are in atomic context, but cgroup_event_remove() may
-* sleep, so we have to call it in workqueue.
+* If the event has been detached at cgroup removal, we
+* can simply return knowing the other side will cleanup
+* for us.
+*
+* We can't race against event freeing since the other
+* side will require wqh->lock via remove_wait_queue(),
+* which we hold.
*/
- schedule_work(>remove);
+ spin_lock(>event_list_lock);
+ if (!list_empty(>list)) {
+ list_del_init(>list);
+ /*
+* We are in atomic context, but cgroup_event_remove()
+* may sleep, so we have to call it in workqueue.
+*/
+ schedule_work(>remove);
+ }
+ spin_unlock(>event_list_lock);
}
return 0;
@@ -4428,20 +4451,15 @@ static int cgroup_destroy_locked(struct cgroup *cgrp)
/*
* Unregister events and notify userspace.
* Notify userspace about cgroup removing only after rmdir of cgroup
-* directory to avoid race between userspace and kernelspace. Use
-* a temporary list to avoid a deadlock with cgroup_event_wake(). Since
-* cgroup_event_wake() is called with the wait queue head locked,
-* remove_wait_queue() cannot be called while holding event_list_lock.
+* directory to avoid race between userspace and kernelspace.
*/
spin_lock(>event_list_lock);
- list_splice_init(>event_list, _list);
- spin_unlock(>event_list_lock);
- list_for_each_entry_safe(event, tmp, _list, list) {
+ list_for_each_entry_safe(event, tmp, >event_list, list) {
+ event->signal_on_remove = true;
list_del_init(>list);
- remove_wait_queue(event->wqh, >wait);
- eventfd_signal(event->eventfd, 1);
schedule_work(>remove);
}
+ spin_unlock(>event_list_lock);
return 0;
}
--
1.8.0.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: [RFC 1/3] power_supply: Define Binding for supplied-nodes
On Sunday 17 February 2013 04:08 AM, Anton Vorontsov wrote: [...] > > "supplied nodes" sounds confusing (doesn't reflect direction), IMO. I'd > rather call it power-supply,supplied-to = <_battery>; > > But... I'm recalling there was a similar discussion not that long ago, and > Arnd came up with the idea that supplied-to is not fully in spirit of DT, > and proposed his view of proper bindings. Please find the discussion here: > > http://lkml.org/lkml/2012/9/14/104 'supplied-to or supplied nodes' is specific to "power-supply core and battery managed devices/drivers" and not platform specific. Dependent battery drivers interacts/shares power supply events with the help of 'supplied_to' 'num_supplicants' and external_power_changed(...) identifiers which are defined and fixed during driver design, it will be more meaningful to have it internal to drivers instead DT. Ref: ab8500_[fg,btemp,charger].c, abx500_chargalg.c and arch/arm/boot/dts/dbx5x0.dtsi Thanks, Rajanikanth [...] -- 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: build warning after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
ppc44x_defconfig) produced this warning:
net/ipv6/xfrm6_mode_tunnel.c: In function 'xfrm6_mode_tunnel_input':
net/ipv6/xfrm6_mode_tunnel.c:72:2: warning: suggest parentheses around
assignment used as truth value [-Wparentheses]
Introduced by commit 14bbd6a565e1 ("net: Add skb_unclone() helper
function").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpwnUtGCddje.pgp
Description: PGP signature
Re: [PATCH 8/9] [HACK] ARM: imx: work around v7_cpu_resume link error
On Sat, Feb 16, 2013 at 12:14:49AM -0500, Nicolas Pitre wrote: > On Fri, 15 Feb 2013, Russell King - ARM Linux wrote: > > > On Thu, Feb 14, 2013 at 11:47:50PM +0100, Arnd Bergmann wrote: > > > Patch c08e20d24 "arm: Add v7_invalidate_l1 to cache-v7.S" > > > moves the v7_invalidate_l1 symbol out of imx/headsmp.S, > > > which seems to cause a link error because it is now > > > too far away from v7_cpu_resume when building an > > > allyesconfig kernel. > > > > > > If we move the v7_cpu_resume function from the .data > > > section to .text, that creates another link error > > > for the reference to phys_l2x0_saved_regs, but we > > > can move all of the above to .text. > > > > > > I believe that this is not a correct bug fix but just > > > a bad workaround, so I'm open to ideas from people > > > who understand the bigger picture. > > > > Unfortunately, this ends up with writable data in the .text section, which > > is supposed to be read-only. We should try to preserve that status, even > > though we don't enforce it. > > > > I guess the problem is that we end up with the .data segment soo far away > > from the .text segment that these branches no longer work (and remember > > that this code executes with the MMU off.) > > > > The only solution I can think is that we need to do quite a bit of magic > > here to jump to an absolute address, but taking account of the V:P offset. > > That's not going to be particularly nice, and it's going to then also have > > to jump back the other way - to the cpu_resume code which is also in the > > .data section. > > Something like this should work: > > diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S > index 7e49deb128..9de26f3edb 100644 > --- a/arch/arm/mach-imx/headsmp.S > +++ b/arch/arm/mach-imx/headsmp.S > @@ -99,8 +99,11 @@ phys_l2x0_saved_regs: > #endif > > ENTRY(v7_cpu_resume) > - bl v7_invalidate_l1 > + ldr ip, 2f > + mov lr, pc > +1: add pc, pc, ip > pl310_resume > b cpu_resume > +2: .word v7_invalidate_l1 - 1b - 8 > ENDPROC(v7_cpu_resume) > #endif > Yes, it works. > > However it is probably best to move all the code to the .text section > where it belongs and fixup the data access instead. I must plead guilty > for introducing this idea of putting code in the .data section with the > SA1100resume code over 10 years ago that everyone copied since. > > So here's how I think it should look instead, and how I should have done > the SA1100 code back then: > > diff --git a/arch/arm/mach-imx/headsmp.S b/arch/arm/mach-imx/headsmp.S > index 7e49deb128..38a544a037 100644 > --- a/arch/arm/mach-imx/headsmp.S > +++ b/arch/arm/mach-imx/headsmp.S > @@ -73,16 +73,16 @@ ENDPROC(v7_secondary_startup) > > #ifdef CONFIG_PM > /* > - * The following code is located into the .data section. This is to > - * allow phys_l2x0_saved_regs to be accessed with a relative load > - * as we are running on physical address here. > + * The following code must assume it is running from physical address > + * where absolute virtual addresses to the data section have to be > + * turned into relative ones. > */ > - .data > - .align > > #ifdef CONFIG_CACHE_L2X0 > .macro pl310_resume > - ldr r2, phys_l2x0_saved_regs > + adr r0, phys_l2x0_saved_ptr_offset > + ldr r2, [r0] > + add r2, r2, r0 > ldr r0, [r2, #L2X0_R_PHY_BASE] @ get physical base of l2x0 > ldr r1, [r2, #L2X0_R_AUX_CTRL] @ get aux_ctrl value > str r1, [r0, #L2X0_AUX_CTRL]@ restore aux_ctrl > @@ -90,9 +90,13 @@ ENDPROC(v7_secondary_startup) > str r1, [r0, #L2X0_CTRL]@ re-enable L2 > .endm > > + .bss > .globl phys_l2x0_saved_regs > phys_l2x0_saved_regs: > -.long 0 > +.space 4 > + .previous > +phys_l2x0_saved_ptr_offset: > + .word phys_l2x0_saved_regs - . > #else > .macro pl310_resume > .endm > But this does not work. It seems the execution jumps to the start of kernel on system resuming. Shawn root@freescale ~$ ./rtcwakeup.sh rtcwakeup.out: wakeup from "mem" using rtc0 at Fri Jan 2 00:09:43 1970 PM: Syncing filesystems ... done. PM: Preparing system for mem sleep mmc0: card a8a5 removed mmc1: card b368 removed Freezing user space processes ... (elapsed 0.01 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. PM: Entering mem sleep fec_stop : Graceful transmit stop did not complete ! PM: suspend of devices complete after 8.361 msecs PM: suspend devices took 0.010 seconds PM: late suspend of devices complete after 0.267 msecs PM: noirq suspend of devices complete after 0.754 msecs Disabling non-boot CPUs ... CPU1: shutdown CPU2: shutdown CPU3: shutdown Booting Linux on physical CPU 0x0 Linux version 3.8.0-rc7-next-20130215+ (r65073@S2101-09) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #341 SMP Mon Feb 18 13:36:48 CST 2013
Re: [RFC PATCH v3 0/3] sched: simplify the select_task_rq_fair()
On 01/29/2013 05:08 PM, Michael Wang wrote: > v3 change log: > Fix small logical issues (Thanks to Mike Galbraith). > Change the way of handling WAKE. > > This patch set is trying to simplify the select_task_rq_fair() with > schedule balance map. > > After get rid of the complex code and reorganize the logical, pgbench show > the improvement, more the clients, bigger the improvement. > > Prev: Post: > > | db_size | clients | | tps | | tps | > +-+-+ +---+ +---+ > | 22 MB | 1 | | 10788 | | 10881 | > | 22 MB | 2 | | 21617 | | 21837 | > | 22 MB | 4 | | 41597 | | 42645 | > | 22 MB | 8 | | 54622 | | 57808 | > | 22 MB | 12 | | 50753 | | 54527 | > | 22 MB | 16 | | 50433 | | 56368 | +11.77% > | 22 MB | 24 | | 46725 | | 54319 | +16.25% > | 22 MB | 32 | | 43498 | | 54650 | +25.64% > | 7484 MB | 1 | | 7894 | | 8301 | > | 7484 MB | 2 | | 19477 | | 19622 | > | 7484 MB | 4 | | 36458 | | 38242 | > | 7484 MB | 8 | | 48423 | | 50796 | > | 7484 MB | 12 | | 46042 | | 49938 | > | 7484 MB | 16 | | 46274 | | 50507 | +9.15% > | 7484 MB | 24 | | 42583 | | 49175 | +15.48% > | 7484 MB | 32 | | 36413 | | 49148 | +34.97% > | 15 GB | 1 | | 7742 | | 7876 | > | 15 GB | 2 | | 19339 | | 19531 | > | 15 GB | 4 | | 36072 | | 37389 | > | 15 GB | 8 | | 48549 | | 50570 | > | 15 GB | 12 | | 45716 | | 49542 | > | 15 GB | 16 | | 46127 | | 49647 | +7.63% > | 15 GB | 24 | | 42539 | | 48639 | +14.34% > | 15 GB | 32 | | 36038 | | 48560 | +34.75% > > Please check the patch for more details about schedule balance map. > > Support the NUMA domain but not well tested. > Support the rebuild of domain but not tested. Hi, Ingo, Peter I've finished the test I could figure out (NUMA, domain rebuild...) , no issue appear on my box. I think this patch set will benefit the system, especially when there are huge amount of cpus. How do you think about this idea? do you have any comments on the patch set? Regards, Michael Wang > > Comments are very welcomed. > > Behind the v3: > Some changes has been applied to the way of handling WAKE. > > And that's all around one question, whether we should do load balance > for WAKE or not? > > In the old world, the only chance to do load balance for WAKE is when > prev cpu and curr cpu are not cache affine, but that doesn't make sense. > > I suppose the real meaning behind that logical is, do balance only if > cache benefit nothing after changing cpu. > > However, select_idle_sibling() is not only designed for the purpose to > take care of cache, it also benefit latency, and cost less than the > balance path. > > Besides, it's impossible to estimate the benefit of doing load balance > at that point of time. > > And that's come out the v3, no load balance for WAKE. > > Test with: > 12 cpu X86 server and linux-next 3.8.0-rc3. > > Michael Wang (3): > [RFC PATCH v3 1/3] sched: schedule balance map foundation > [RFC PATCH v3 2/3] sched: build schedule balance map > [RFC PATCH v3 3/3] sched: simplify select_task_rq_fair() with schedule > balance map > > Signed-off-by: Michael Wang > --- > b/kernel/sched/core.c | 44 +++ > b/kernel/sched/fair.c | 135 > ++--- > b/kernel/sched/sched.h | 14 + > kernel/sched/core.c| 67 > 4 files changed, 199 insertions(+), 61 deletions(-) > > -- > 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/
linux-next: manual merge of the akpm tree with the kbuild tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
kernel/timeconst.pl between commit 70730bca1331 ("kernel: Replace
timeconst.pl with a bc script") from the kbuild tree and commit
"timeconst.pl: remove deprecated defined(@array)" from the akpm tree.
I just dropped the akpm tree patch since the file had been deleted by the
kbuild tree commit.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp2b7v4kW0Ui.pgp
Description: PGP signature
Re: prctl(PR_SET_MM)
On 02/17/13 17:39, Amnon Shiloh wrote: > Hello, > > The code in "kernel/sys.c" provides the "prctl(PR_SET_MM)" function, > which is the only way a process can set or modify the following 11 > per-process fields: > > start_code, end_code, start_data, end_data, start_brk, brk, > start_stack, arg_start, arg_end, env_start, env_end. > > Being able to set those fields is important, even crucial, > for any conceivable user-level checkpointing software, as > well as for migrating processes between different computers. > > Unfortunately, this code (essentially "prctl_set_mm()") is presently > enclosed in "#ifdef CONFIG_CHECKPOINT_RESTORE" which is configured > as "default n" in "init/Kconfig". Many system-administrators who > may like to have a checkpoint/restore or process-migration facility, > but use standard pre-packaged kernels, find the requirement to > configure and compile their own non-standard kernel difficult or > too prohibitive. > > Would it be possible to have this code enabled by default? > > This could be done in one of 4 ways: > 1) Having CONFIG_CHECKPOINT_RESTORE enabled by default; or > 2) Releasing this code from the "#ifdef CONFIG_CHECK_RESTORE"; or > 3) Placing this code within a different kernel-configuration option >(say "CONFIG_BASIC_CHECKPOINTING") that is enabled by default; or > 4) Placing this code under a dual #if, so instead of: >#ifdef CONFIG_CHECKPOINT_RESTORE > have: >#if defined(CONFIG_CHECKPOINT_RESTORE) || > defined(CONFIG_BASIC_CHECKPOINTING) This is basically a distro issue. Distros can choose to enable this code by default, but the Linux kernel that Linus maintains does not need to enable it. -- ~Randy -- 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] staging: android: ashmem: get_name,set_name not to hold ashmem_mutex
Hi, I'm working on Android Linux Kernel (version 3.4) and seeing a "deadlock" in the ashmem driver, while handling mmap request. I seek your support to fix the same. The locks that involved in the dead lock are 1) mm->mmap_sem 2) ashmem_mutex The following is the sequence of events that leads to the deadlock. There are two threads A and B that belong to the same process (system_server) and hence share the mm struct. A1) In the A's context an mmap system call is made with an fd of ashmem A2) The system call sys_mmap_pgoff acquires the mmap_sem of the "mm" and sleeps before calling the .mmap of ashmem i.e before calling ashmem_mmap and acquiring the ashmem_mutex from this function. Now the thread B runs and proceeds to do the following B1) In the B's context ashmem ioctl with option ASHMEM_GET_NAME is called. B2) Now the code proceeds to acquire the ashmem_mutex and performs a "copy_to_user" B3) copy_to_user raises a valid exception to copy the data from user space and proceeds to handle it gracefully, do_DataAbort --> do_page_fault (This condition can happen if the physical page for the give user address is not mapped yet). B4) In do_page_fault it finds that the mm->mmap_sem is not available (Note A & B share the mm) since A has it and sleeps Now the thread A runs again A3) It proceeds to call ashmem_mmap and tries to acquired ashmem_mutex, which is not available (is with B) and sleeps. Now A has acquired mmap_sem and waits for B to release ashmem_mutex B has acquired ashmem_mutex and waits for the mmap_sem to be available, which is held by A. This creates a dead lock in the system. Proposed Solution: Do not hold the ashmem lock while making copy_to_user/copy_from_user calls. At the same ensure that data integrity is maintained (two threads calling SET_NAME/GET_NAME should not lead to issues). I have attached a patch to fix this problem. How to Reproduce the problem: In normal circumstances it is very hard to see this. The problem was seen during regression tests, but was very rare. My Kernel Version is 3.4.0 and I managed to write a unit test case to create this issue almost 100% of the time. Testing: Used the same unit test case to ensure that the attached patch fixes the deadlock in Kernel Version 3.4 Ported the same patch to 3.8 for submission. Please provide your feedback on the patch. Warm Regards, Shankar 0001-staging-android-ashmem-get_name-set_name-not-to-hold.patch Description: Binary data
RE: [PATCH v4 2/8] watchdog/at91sam9_wdt: Remove at91wdt_private and add at91wdt_drvdata struct
Hi Wim > I rather have this after the conversion of the watchdog to the new framework. > Thanks a lot. OK , I will do it later. Best Regards, Wenyou Yang -- 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/
Please don't send update emails to me
Please don't send update emails to me
Whenever I need I can check from website
Thanks & Regards
Chun-Shian Tsai
- Original Message -
From: "Kumar, Anil"
To: ; ;
Cc:
Sent: Monday, February 18, 2013 11:42 AM
Subject: RE: [PATCH V2] watchdog: davinci_wdt: update to devm_* API
Hi,
On Fri, Feb 08, 2013 at 13:09:30, Kumar, Anil wrote:
Update the code to use devm_* API so that driver
core will manage resources.
Signed-off-by: Kumar, Anil
---
This patch applies on top of v3.8-rc6.
Tested on da850 EVM.
Changes for V2:
- Use return -EADDRNOTAVAIL in case of devm_request_and_ioremap() fail.
- Use devm_clk_get() instead of clk_get().
- Revert back the change for *dev.
- Removes static type for "wdt_mem" structure as it is used only
inside the function now.
Gentle Ping. As there are no review comments on this patch,
Could you please pull this patch ?
:100644 100644 e8e8724... 7df1fdc... M drivers/watchdog/davinci_wdt.c
drivers/watchdog/davinci_wdt.c | 29 ++---
1 files changed, 6 insertions(+), 23 deletions(-)
diff --git a/drivers/watchdog/davinci_wdt.c
b/drivers/watchdog/davinci_wdt.c
index e8e8724..7df1fdc 100644
--- a/drivers/watchdog/davinci_wdt.c
+++ b/drivers/watchdog/davinci_wdt.c
@@ -69,7 +69,6 @@ static unsigned long wdt_status;
#define WDT_REGION_INITED 2
#define WDT_DEVICE_INITED 3
-static struct resource *wdt_mem;
static void __iomem *wdt_base;
struct clk *wdt_clk;
@@ -201,10 +200,11 @@ static struct miscdevice davinci_wdt_miscdev = {
static int davinci_wdt_probe(struct platform_device *pdev)
{
- int ret = 0, size;
+ int ret = 0;
struct device *dev = >dev;
+ struct resource *wdt_mem;
- wdt_clk = clk_get(dev, NULL);
+ wdt_clk = devm_clk_get(dev, NULL);
if (WARN_ON(IS_ERR(wdt_clk)))
return PTR_ERR(wdt_clk);
@@ -221,43 +221,26 @@ static int davinci_wdt_probe(struct platform_device
*pdev)
return -ENOENT;
}
- size = resource_size(wdt_mem);
- if (!request_mem_region(wdt_mem->start, size, pdev->name)) {
- dev_err(dev, "failed to get memory region\n");
- return -ENOENT;
- }
-
- wdt_base = ioremap(wdt_mem->start, size);
+ wdt_base = devm_request_and_ioremap(dev, wdt_mem);
if (!wdt_base) {
- dev_err(dev, "failed to map memory region\n");
- release_mem_region(wdt_mem->start, size);
- wdt_mem = NULL;
- return -ENOMEM;
+ dev_err(dev, "ioremap failed\n");
+ return -EADDRNOTAVAIL;
}
ret = misc_register(_wdt_miscdev);
if (ret < 0) {
dev_err(dev, "cannot register misc device\n");
- release_mem_region(wdt_mem->start, size);
- wdt_mem = NULL;
} else {
set_bit(WDT_DEVICE_INITED, _status);
}
- iounmap(wdt_base);
return ret;
}
static int davinci_wdt_remove(struct platform_device *pdev)
{
misc_deregister(_wdt_miscdev);
- if (wdt_mem) {
- release_mem_region(wdt_mem->start, resource_size(wdt_mem));
- wdt_mem = NULL;
- }
-
clk_disable_unprepare(wdt_clk);
- clk_put(wdt_clk);
return 0;
}
--
1.7.4.1
Thanks,
Anil
___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
This email may contain confidential information. Please do not use or disclose
it in any way and delete it if you are not the intended recipient.
--
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: manual merge of the userns tree with the nfsd tree
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in
net/sunrpc/svcauth_unix.c between commit 2d4383383b0b ("SUNRPC: rework
cache upcall logic") from the nfsd tree and commit 7eaf040b720b ("sunrpc:
Use kuid_t and kgid_t where appropriate") 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 net/sunrpc/svcauth_unix.c
index 5085804,a1852e1..000
--- a/net/sunrpc/svcauth_unix.c
+++ b/net/sunrpc/svcauth_unix.c
@@@ -465,7 -475,12 +470,7 @@@ static void unix_gid_request(struct cac
(*bpp)[-1] = '\n';
}
- static struct unix_gid *unix_gid_lookup(struct cache_detail *cd, uid_t uid);
-static int unix_gid_upcall(struct cache_detail *cd, struct cache_head *h)
-{
- return sunrpc_cache_pipe_upcall(cd, h, unix_gid_request);
-}
-
+ static struct unix_gid *unix_gid_lookup(struct cache_detail *cd, kuid_t uid);
static int unix_gid_parse(struct cache_detail *cd,
char *mesg, int mlen)
pgpL_LG9wI4vl.pgp
Description: PGP signature
RE: [PATCH v4 3/8] watchdog/at91sam9_wdt: Convert to use the watchdog framework
Hi Wim, > This code not only converts the watchdog to the new framework, > but it also adds the is_enable related code changes which should > be a seperate patch. > > So I took your original patch and changed it to the below at91sam9_wdt > watchdog conversion patch. Note: this is also without Fabio's timeout-sec > patch, this one needs to come after the conversion. > > Please test this patch and let me know if this works (the watchdog should > behave the same before as after this patch). Sorry for so late reply due to Chinese New Year's holiday. I applied it on the linux-watchdog trees, and tested it on at91sam9m10g45ek both DT and non-DT support, at91sam9g25ek with DT support. It works OK after one compilation error fixed. > + at91wdt_private.next_heartbeat = jiffies + wdd->timeout * HZ; + at91wdt_private.next_heartbeat = jiffies + at91_wdt_dev.timeout * HZ; Thank you very much. Best Regards, Wenyou Yang -- 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 2/2 RESEND] video: exynos_dp: move disable_irq() to exynos_dp_suspend()
From: Ajay Kumar
disable_irq() should be moved to exynos_dp_suspend(), because
enable_irq() is called at exynos_dp_resume().
Signed-off-by: Ajay Kumar
Signed-off-by: Jingoo Han
---
drivers/video/exynos/exynos_dp_core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c
b/drivers/video/exynos/exynos_dp_core.c
index c7374c0..de9d4da 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -1124,8 +1124,6 @@ static int exynos_dp_remove(struct platform_device *pdev)
struct exynos_dp_platdata *pdata = pdev->dev.platform_data;
struct exynos_dp_device *dp = platform_get_drvdata(pdev);
- disable_irq(dp->irq);
-
flush_work(>hotplug_work);
if (pdev->dev.of_node) {
@@ -1148,6 +1146,8 @@ static int exynos_dp_suspend(struct device *dev)
struct exynos_dp_platdata *pdata = dev->platform_data;
struct exynos_dp_device *dp = dev_get_drvdata(dev);
+ disable_irq(dp->irq);
+
flush_work(>hotplug_work);
if (dev->of_node) {
--
1.7.2.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 1/2 RESEND] video: exynos_dp: add missing of_node_put()
of_find_node_by_name() returns a node pointer with refcount
incremented, use of_node_put() on it when done.
of_find_node_by_name() will call of_node_put() against
the node pass to from parameter, thus we also need to call
of_node_get(from) before calling of_find_node_by_name().
Signed-off-by: Jingoo Han
---
drivers/video/exynos/exynos_dp_core.c | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c
b/drivers/video/exynos/exynos_dp_core.c
index 2ed9776..c7374c0 100644
--- a/drivers/video/exynos/exynos_dp_core.c
+++ b/drivers/video/exynos/exynos_dp_core.c
@@ -965,10 +965,11 @@ static struct exynos_dp_platdata
*exynos_dp_dt_parse_pdata(struct device *dev)
static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
{
- struct device_node *dp_phy_node;
+ struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
u32 phy_base;
+ int ret = 0;
- dp_phy_node = of_find_node_by_name(dp->dev->of_node, "dptx-phy");
+ dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
if (!dp_phy_node) {
dev_err(dp->dev, "could not find dptx-phy node\n");
return -ENODEV;
@@ -976,22 +977,28 @@ static int exynos_dp_dt_parse_phydata(struct
exynos_dp_device *dp)
if (of_property_read_u32(dp_phy_node, "reg", _base)) {
dev_err(dp->dev, "faild to get reg for dptx-phy\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto err;
}
if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
>enable_mask)) {
dev_err(dp->dev, "faild to get enable-mask for dptx-phy\n");
- return -EINVAL;
+ ret = -EINVAL;
+ goto err;
}
dp->phy_addr = ioremap(phy_base, SZ_4);
if (!dp->phy_addr) {
dev_err(dp->dev, "failed to ioremap dp-phy\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto err;
}
- return 0;
+err:
+ of_node_put(dp_phy_node);
+
+ return ret;
}
static void exynos_dp_phy_init(struct exynos_dp_device *dp)
--
1.7.2.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 5/5 RESEND] video: s3c-fb: Fix typo in definition of VIDCON1_VSTATUS_FRONTPORCH value
From: Tomasz Figa The correct value for VIDCON1_VSTATUS_FRONTPORCH is 3, not 0. Signed-off-by: Tomasz Figa Signed-off-by: Kyungmin Park Signed-off-by: Jingoo Han --- include/video/samsung_fimd.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h index 2f95d9a..b039320 100644 --- a/include/video/samsung_fimd.h +++ b/include/video/samsung_fimd.h @@ -82,7 +82,7 @@ #define VIDCON1_VSTATUS_VSYNC (0x0 << 13) #define VIDCON1_VSTATUS_BACKPORCH (0x1 << 13) #define VIDCON1_VSTATUS_ACTIVE (0x2 << 13) -#define VIDCON1_VSTATUS_FRONTPORCH (0x0 << 13) +#define VIDCON1_VSTATUS_FRONTPORCH (0x3 << 13) #define VIDCON1_VCLK_MASK (0x3 << 9) #define VIDCON1_VCLK_HOLD (0x0 << 9) #define VIDCON1_VCLK_RUN (0x1 << 9) -- 1.7.2.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: [PATCH v3 1/1] tools/power x86_energy_perf_policy: fix cpuid for i686
On Thursday 14 February 2013 14:35:58 Benson Leung wrote:
> + asm volatile ("mov %%ebx, %%edi;" /* save ebx (for PIC) */
> + "cpuid;"
> + "mov %%ebx, %%esi;" /* pass to caller */
> + "mov %%edi, %%ebx;" /* restore ebx */
> + :"+a" (_eax), "=S" (_ebx), "=c" (_ecx), "=d" (_edx)
> + : /* inputs: eax is handled above */
> + :"edi" /* clobbers: we hit edi directly */);
i've written a better version since:
https://github.com/linux-test-project/ltp/blob/master/include/ltp_cpuid.h
-mike
signature.asc
Description: This is a digitally signed message part.
[PATCH 4/5 RESEND] video: s3c-fb: add the bit definitions for CSC EQ709 and EQ601
This patch adds the bit definitions for CSC EQ709 and EQ601. These definitons are used to control the CSC parameter such as equation 709 and equation 601. Signed-off-by: Jingoo Han --- include/video/samsung_fimd.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h index be7b853..2f95d9a 100644 --- a/include/video/samsung_fimd.h +++ b/include/video/samsung_fimd.h @@ -176,6 +176,8 @@ /* WINCONx */ #define WINCON(_win) (0x20 + ((_win) * 4)) +#define WINCONx_CSCCON_EQ601 (0x0 << 28) +#define WINCONx_CSCCON_EQ709 (0x1 << 28) #define WINCONx_CSCWIDTH_MASK (0x3 << 26) #define WINCONx_CSCWIDTH_SHIFT 26 #define WINCONx_CSCWIDTH_WIDE (0x0 << 26) -- 1.7.2.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 4/4] regulator: palmas: Change the DT node property names to follow the convention
DT node properties should not have "_". Replacing them by "-". Signed-off-by: J Keerthy --- drivers/regulator/palmas-regulator.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c index 22c6ae2..a7d1d53 100644 --- a/drivers/regulator/palmas-regulator.c +++ b/drivers/regulator/palmas-regulator.c @@ -551,17 +551,17 @@ static void palmas_dt_to_pdata(struct device *dev, sizeof(struct palmas_reg_init), GFP_KERNEL); ret = of_property_read_u32(palmas_matches[idx].of_node, - "ti,warm_reset", ); + "ti,warm-reset", ); if (!ret) pdata->reg_init[idx]->warm_reset = prop; ret = of_property_read_u32(palmas_matches[idx].of_node, - "ti,roof_floor", ); + "ti,roof-floor", ); if (!ret) pdata->reg_init[idx]->roof_floor = prop; ret = of_property_read_u32(palmas_matches[idx].of_node, - "ti,mode_sleep", ); + "ti,mode-sleep", ); if (!ret) pdata->reg_init[idx]->mode_sleep = prop; @@ -576,7 +576,7 @@ static void palmas_dt_to_pdata(struct device *dev, pdata->reg_init[idx]->vsel = prop; } - ret = of_property_read_u32(node, "ti,ldo6_vibrator", ); + ret = of_property_read_u32(node, "ti,ldo6-vibrator", ); if (!ret) pdata->ldo6_vibrator = prop; } -- 1.7.5.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 3/5 RESEND] video: s3c-fb: remove unnecessary brackets
This patch removes unnecessary brackets and the duplicated VIDTCON2 definition. Also, header comment is modified, because EXYNOS series is supported and is not available. Signed-off-by: Jingoo Han --- include/video/samsung_fimd.h | 199 - 1 files changed, 97 insertions(+), 102 deletions(-) diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h index 0865256..be7b853 100644 --- a/include/video/samsung_fimd.h +++ b/include/video/samsung_fimd.h @@ -8,12 +8,8 @@ * S3C Platform - new-style fimd and framebuffer register definitions * * This is the register set for the fimd and new style framebuffer interface - * found from the S3C2443 onwards into the S3C2416, S3C2450 and the - * S3C64XX series such as the S3C6400 and S3C6410. - * - * The file does not contain the cpu specific items which are based on - * whichever architecture is selected, it only contains the core of the - * register set. See to get the specifics. + * found from the S3C2443 onwards into the S3C2416, S3C2450, the + * S3C64XX series such as the S3C6400 and S3C6410, and EXYNOS series. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -22,10 +18,10 @@ /* VIDCON0 */ -#define VIDCON0(0x00) +#define VIDCON00x00 #define VIDCON0_INTERLACE (1 << 29) #define VIDCON0_VIDOUT_MASK(0x7 << 26) -#define VIDCON0_VIDOUT_SHIFT (26) +#define VIDCON0_VIDOUT_SHIFT 26 #define VIDCON0_VIDOUT_RGB (0x0 << 26) #define VIDCON0_VIDOUT_TV (0x1 << 26) #define VIDCON0_VIDOUT_I80_LDI0(0x2 << 26) @@ -35,7 +31,7 @@ #define VIDCON0_VIDOUT_WB_I80_LDI1 (0x7 << 26) #define VIDCON0_L1_DATA_MASK (0x7 << 23) -#define VIDCON0_L1_DATA_SHIFT (23) +#define VIDCON0_L1_DATA_SHIFT 23 #define VIDCON0_L1_DATA_16BPP (0x0 << 23) #define VIDCON0_L1_DATA_18BPP16(0x1 << 23) #define VIDCON0_L1_DATA_18BPP9 (0x2 << 23) @@ -44,7 +40,7 @@ #define VIDCON0_L1_DATA_16BPP8 (0x5 << 23) #define VIDCON0_L0_DATA_MASK (0x7 << 20) -#define VIDCON0_L0_DATA_SHIFT (20) +#define VIDCON0_L0_DATA_SHIFT 20 #define VIDCON0_L0_DATA_16BPP (0x0 << 20) #define VIDCON0_L0_DATA_18BPP16(0x1 << 20) #define VIDCON0_L0_DATA_18BPP9 (0x2 << 20) @@ -53,7 +49,7 @@ #define VIDCON0_L0_DATA_16BPP8 (0x5 << 20) #define VIDCON0_PNRMODE_MASK (0x3 << 17) -#define VIDCON0_PNRMODE_SHIFT (17) +#define VIDCON0_PNRMODE_SHIFT 17 #define VIDCON0_PNRMODE_RGB(0x0 << 17) #define VIDCON0_PNRMODE_BGR(0x1 << 17) #define VIDCON0_PNRMODE_SERIAL_RGB (0x2 << 17) @@ -61,14 +57,14 @@ #define VIDCON0_CLKVALUP (1 << 16) #define VIDCON0_CLKVAL_F_MASK (0xff << 6) -#define VIDCON0_CLKVAL_F_SHIFT (6) -#define VIDCON0_CLKVAL_F_LIMIT (0xff) +#define VIDCON0_CLKVAL_F_SHIFT 6 +#define VIDCON0_CLKVAL_F_LIMIT 0xff #define VIDCON0_CLKVAL_F(_x) ((_x) << 6) #define VIDCON0_VLCKFREE (1 << 5) #define VIDCON0_CLKDIR (1 << 4) #define VIDCON0_CLKSEL_MASK(0x3 << 2) -#define VIDCON0_CLKSEL_SHIFT (2) +#define VIDCON0_CLKSEL_SHIFT 2 #define VIDCON0_CLKSEL_HCLK(0x0 << 2) #define VIDCON0_CLKSEL_LCD (0x1 << 2) #define VIDCON0_CLKSEL_27M (0x3 << 2) @@ -76,13 +72,13 @@ #define VIDCON0_ENVID (1 << 1) #define VIDCON0_ENVID_F(1 << 0) -#define VIDCON1(0x04) +#define VIDCON10x04 #define VIDCON1_LINECNT_MASK (0x7ff << 16) -#define VIDCON1_LINECNT_SHIFT (16) +#define VIDCON1_LINECNT_SHIFT 16 #define VIDCON1_LINECNT_GET(_v)(((_v) >> 16) & 0x7ff) #define VIDCON1_FSTATUS_EVEN (1 << 15) #define VIDCON1_VSTATUS_MASK (0x3 << 13) -#define VIDCON1_VSTATUS_SHIFT (13) +#define VIDCON1_VSTATUS_SHIFT 13 #define VIDCON1_VSTATUS_VSYNC (0x0 << 13) #define VIDCON1_VSTATUS_BACKPORCH (0x1 << 13) #define VIDCON1_VSTATUS_ACTIVE (0x2 << 13) @@ -98,12 +94,12 @@ /* VIDCON2 */ -#define VIDCON2
[PATCH 3/4] regulator: palmas: Removing duplicated code
Removing duplicate assignment in the existing code. Signed-off-by: J Keerthy --- drivers/regulator/palmas-regulator.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c index c9e912f..22c6ae2 100644 --- a/drivers/regulator/palmas-regulator.c +++ b/drivers/regulator/palmas-regulator.c @@ -566,11 +566,6 @@ static void palmas_dt_to_pdata(struct device *dev, pdata->reg_init[idx]->mode_sleep = prop; ret = of_property_read_u32(palmas_matches[idx].of_node, - "ti,warm_reset", ); - if (!ret) - pdata->reg_init[idx]->warm_reset = prop; - - ret = of_property_read_u32(palmas_matches[idx].of_node, "ti,tstep", ); if (!ret) pdata->reg_init[idx]->tstep = prop; -- 1.7.5.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 2/4] mfd: palmas: Change the DT node property names to follow the convention
DT node properties should not have "_". Replacing them by "-".
Signed-off-by: J Keerthy
---
drivers/mfd/palmas.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 6ffd7a2..d8467cf 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -253,20 +253,20 @@ static void palmas_dt_to_pdata(struct device_node *node,
int ret;
u32 prop;
- ret = of_property_read_u32(node, "ti,mux_pad1", );
+ ret = of_property_read_u32(node, "ti,mux-pad1", );
if (!ret) {
pdata->mux_from_pdata = 1;
pdata->pad1 = prop;
}
- ret = of_property_read_u32(node, "ti,mux_pad2", );
+ ret = of_property_read_u32(node, "ti,mux-pad2", );
if (!ret) {
pdata->mux_from_pdata = 1;
pdata->pad2 = prop;
}
/* The default for this register is all masked */
- ret = of_property_read_u32(node, "ti,power_ctrl", );
+ ret = of_property_read_u32(node, "ti,power-ctrl", );
if (!ret)
pdata->power_ctrl = prop;
else
--
1.7.5.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 2/5 RESEND] video: s3c-fb: remove duplicated S3C_FB_MAX_WIN
S3C_FB_MAX_WIN is already defined in 'plat-samsung/include/plat/fb.h'. So, this definition in 'include/video/samsung_fimd.h' should be removed to avoid the duplication. Signed-off-by: Jingoo Han --- include/video/samsung_fimd.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h index e755448..0865256 100644 --- a/include/video/samsung_fimd.h +++ b/include/video/samsung_fimd.h @@ -438,8 +438,6 @@ #define BLENDCON_NEW_8BIT_ALPHA_VALUE (1 << 0) #define BLENDCON_NEW_4BIT_ALPHA_VALUE (0 << 0) -#define S3C_FB_MAX_WIN (5) /* number of hardware windows available. */ - /* Notes on per-window bpp settings * * Value Win0 Win1 Win2 Win3 Win 4 -- 1.7.2.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 1/5 RESEND] video: s3c-fb: use ARCH_ dependancy
This patch uses ARCH_ dependancy when using s3c-fb. S3C_DEV_FB, S5P_DEV_FIMD0 cannot be enabled on EXYNOS5. So, ARCH_ should be used as dependancy for s3c-fb. Signed-off-by: Jingoo Han --- drivers/video/Kconfig |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index e7068c5..049fff1 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2025,7 +2025,8 @@ config FB_TMIO_ACCELL config FB_S3C tristate "Samsung S3C framebuffer support" - depends on FB && (S3C_DEV_FB || S5P_DEV_FIMD0) + depends on FB && (CPU_S3C2416 || ARCH_S3C64XX || ARCH_S5P64X0 || \ + ARCH_S5PC100 || ARCH_S5PV210 || ARCH_EXYNOS) select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 1.7.2.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 1/4] documentation: add palmas dts definition
From: Graeme Gregory
Add the DTS definition for the palmas device including the MFD children.
Signed-off-by: Graeme Gregory
[j-keer...@ti.com: changed the DT node property names to follow the
convention]
Signed-off-by: J Keerthy
---
Documentation/devicetree/bindings/mfd/palmas.txt | 67 ++
1 files changed, 67 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/palmas.txt
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
new file mode 100644
index 000..5fa922e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -0,0 +1,67 @@
+Texas Instruments Palmas family
+
+The Palmas familly are Integrated Power Management Chips.
+These chips are connected to an i2c bus.
+
+
+Required properties:
+- compatible : Must be "ti,palmas";
+ For Integrated power-management in the palmas series, twl6035, twl6037,
+ tps65913
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the palmas support several interrupts
internally,
+ it is considered as an interrupt controller cascaded to the SoC one.
+- #interrupt-cells = <1>;
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+- Child nodes contain in the palmas. The palmas family is made of several
+ variants that support a different number of features.
+ The child nodes will thus depend of the capability of the variant.
+- mux-pad1 if a value is given it will be used for the pad1 mux
+- mux-pad2 if a value us given it will be used for the pad2 mux
+- power-ctrl if a value is given it will be written to the POWER_CTRL register
+
+Example:
+/*
+ * Integrated Power Management Chip Palmas
+ */
+palmas@48 {
+compatible = "ti,palmas";
+reg = <0x48>;
+interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
+interrupt-controller;
+#interrupt-cells = <1>;
+interrupt-parent = <>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+ ti,mux-pad1 = <0x00>;
+ ti,mux-pad2 = <0x00>;
+ ti,power-ctrl = <0x03>;
+
+ palmas_pmic {
+ compatible = "ti,palmas_pmic";
+ regulators {
+ smps12_reg: smps12 {
+ regulator-min-microvolt = < 60>;
+regulator-max-microvolt = <150>;
+ regulator-always-on;
+ regulator-boot-on;
+ti,warm-sleep = <0>;
+ti,roof-floor = <0>;
+ti,mode-sleep = <0>;
+ti,warm-reset = <0>;
+ti,tstep = <0>;
+ti,vsel = <0>;
+ };
+ };
+ ti,ldo6-vibrator = <0>;
+ };
+
+palmas_rtc {
+compatible = "ti,palmas_rtc";
+interrupts = <8 9>;
+reg = <0>;
+};
+};
--
1.7.5.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 0/4] mfd: Palmas: Correct the DT Node properties naming convention and add documentation.
The series corrects the DT node properties naming convention and adds Documentation for the Palmas PMIC. Graeme Gregory (1): documentation: add palmas dts definition J Keerthy (3): mfd: palmas: Change the DT node property names to follow the convention regulator: palmas: Removing duplicated code regulator: palmas: Change the DT node property names to follow the convention Documentation/devicetree/bindings/mfd/palmas.txt | 67 ++ drivers/mfd/palmas.c |6 +- drivers/regulator/palmas-regulator.c | 13 +--- 3 files changed, 74 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/palmas.txt -- 1.7.5.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 v5 01/15] sched: set initial value for runnable avg of sched entities.
We need initialize the se.avg.{decay_count, load_avg_contrib} to zero
after a new task forked.
Otherwise random values of above variables cause mess when do new task
enqueue:
enqueue_task_fair
enqueue_entity
enqueue_entity_load_avg
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 26058d0..1743746 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1559,6 +1559,8 @@ static void __sched_fork(struct task_struct *p)
#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
p->se.avg.runnable_avg_period = 0;
p->se.avg.runnable_avg_sum = 0;
+ p->se.avg.decay_count = 0;
+ p->se.avg.load_avg_contrib = 0;
#endif
#ifdef CONFIG_SCHEDSTATS
memset(>se.statistics, 0, sizeof(p->se.statistics));
--
1.7.12
--
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 v5 06/15] sched: log the cpu utilization at rq
The cpu's utilization is to measure how busy is the cpu.
util = cpu_rq(cpu)->avg.runnable_avg_sum
/ cpu_rq(cpu)->avg.runnable_avg_period;
Since the util is no more than 1, we use its percentage value in later
caculations. And set the the FULL_UTIL as 100%.
In later power aware scheduling, we are sensitive for how busy of the
cpu, not how much weight of its load. As to power consuming, it is more
related with cpu busy time, not load weight.
BTW, rq->util can be used for any purposes if needed, not only power
scheduling.
Signed-off-by: Alex Shi
---
kernel/sched/debug.c | 1 +
kernel/sched/fair.c | 4
kernel/sched/sched.h | 4
3 files changed, 9 insertions(+)
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 7ae4c4c..d220354 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -318,6 +318,7 @@ do {
\
P(ttwu_count);
P(ttwu_local);
+ P(util);
#undef P
#undef P64
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fcdb21f..b9a34ab 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1495,8 +1495,12 @@ static void update_cfs_rq_blocked_load(struct cfs_rq
*cfs_rq, int force_update)
static inline void update_rq_runnable_avg(struct rq *rq, int runnable)
{
+ u32 period;
__update_entity_runnable_avg(rq->clock_task, >avg, runnable);
__update_tg_runnable_avg(>avg, >cfs);
+
+ period = rq->avg.runnable_avg_period ? rq->avg.runnable_avg_period : 1;
+ rq->util = rq->avg.runnable_avg_sum * 100 / period;
}
/* Add the load generated by se into cfs_rq's child load-average */
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 7a19792..ac1e107 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -350,6 +350,9 @@ extern struct root_domain def_root_domain;
#endif /* CONFIG_SMP */
+/* the percentage full cpu utilization */
+#define FULL_UTIL 100
+
/*
* This is the main, per-CPU runqueue data structure.
*
@@ -481,6 +484,7 @@ struct rq {
#endif
struct sched_avg avg;
+ unsigned int util;
};
static inline int cpu_of(struct rq *rq)
--
1.7.12
--
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 v5 05/15] sched: add sysfs interface for sched_balance_policy selection
This patch add the power aware scheduler knob into sysfs:
$cat /sys/devices/system/cpu/sched_balance_policy/available_sched_balance_policy
performance powersaving balance
$cat /sys/devices/system/cpu/sched_balance_policy/current_sched_balance_policy
powersaving
This means the using sched balance policy is 'powersaving'.
User can change the policy by commend 'echo':
echo performance >
/sys/devices/system/cpu/sched_balance_policy/current_sched_balance_policy
Signed-off-by: Alex Shi
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 26
kernel/sched/fair.c| 73 ++
2 files changed, 99 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu
b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 6943133..3283a86 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -53,6 +53,32 @@ Description: Dynamic addition and removal of CPU's. This is
not hotplug
the system. Information writtento the file to remove CPU's
is architecture specific.
+What:
/sys/devices/system/cpu/sched_balance_policy/current_sched_balance_policy
+
/sys/devices/system/cpu/sched_balance_policy/available_sched_balance_policy
+Date: Oct 2012
+Contact: Linux kernel mailing list
+Description: CFS scheduler policy showing and setting interface.
+
+ available_sched_balance_policy shows there are 3 kinds of
+ policies:
+ performance, balance and powersaving.
+ current_sched_balance_policy shows current scheduler policy.
+ User can change the policy by writing it.
+
+ Policy decides the CFS scheduler how to distribute tasks onto
+ different CPU unit.
+
+ performance: try to spread tasks onto more CPU sockets,
+ more CPU cores. performance oriented.
+
+ powersaving: try to pack tasks onto same core or same CPU
+ until every LCPUs are busy in the core or CPU socket.
+ powersaving oriented.
+
+ balance: try to pack tasks onto same core or same CPU
+ until full powered CPUs are busy.
+ balance between performance and powersaving.
+
What: /sys/devices/system/cpu/cpu#/node
Date: October 2009
Contact: Linux memory management mailing list
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2f98ffb..fcdb21f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6108,6 +6108,79 @@ static unsigned int get_rr_interval_fair(struct rq *rq,
struct task_struct *task
/* The default scheduler policy is 'performance'. */
int __read_mostly sched_balance_policy = SCHED_POLICY_PERFORMANCE;
+#ifdef CONFIG_SYSFS
+static ssize_t show_available_sched_balance_policy(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "performance balance powersaving\n");
+}
+
+static ssize_t show_current_sched_balance_policy(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ if (sched_balance_policy == SCHED_POLICY_PERFORMANCE)
+ return sprintf(buf, "performance\n");
+ else if (sched_balance_policy == SCHED_POLICY_POWERSAVING)
+ return sprintf(buf, "powersaving\n");
+ else if (sched_balance_policy == SCHED_POLICY_BALANCE)
+ return sprintf(buf, "balance\n");
+ return 0;
+}
+
+static ssize_t set_sched_balance_policy(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ unsigned int ret = -EINVAL;
+ charstr_policy[16];
+
+ ret = sscanf(buf, "%15s", str_policy);
+ if (ret != 1)
+ return -EINVAL;
+
+ if (!strcmp(str_policy, "performance"))
+ sched_balance_policy = SCHED_POLICY_PERFORMANCE;
+ else if (!strcmp(str_policy, "powersaving"))
+ sched_balance_policy = SCHED_POLICY_POWERSAVING;
+ else if (!strcmp(str_policy, "balance"))
+ sched_balance_policy = SCHED_POLICY_BALANCE;
+ else
+ return -EINVAL;
+
+ return count;
+}
+
+/*
+ * * Sysfs setup bits:
+ * */
+static DEVICE_ATTR(current_sched_balance_policy, 0644,
+ show_current_sched_balance_policy, set_sched_balance_policy);
+
+static DEVICE_ATTR(available_sched_balance_policy, 0444,
+ show_available_sched_balance_policy, NULL);
+
+static struct attribute *sched_balance_policy_default_attrs[] = {
+ _attr_current_sched_balance_policy.attr,
+ _attr_available_sched_balance_policy.attr,
+ NULL
+};
+static struct attribute_group sched_balance_policy_attr_group = {
+ .attrs = sched_balance_policy_default_attrs,
+ .name = "sched_balance_policy",
+};
+
+int
Re: [PATCH v2 0/4] nfsd: make is works in a container
15.02.2013 20:20, J. Bruce Fields пишет: On Fri, Feb 01, 2013 at 03:56:05PM +0300, Stanislav Kinsbursky wrote: This patch set finally enables NFSd in container. I've tested it in container with it's own root, and also pid, net and mount namespaces. Thanks, these look fine to me; applying. They should show up in my for-3.9 branch sometime today. Thanks! -- Best regards, Stanislav Kinsbursky -- 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 v5 04/15] sched: add sched balance policies in kernel
Current scheduler behavior is just consider for larger performance of system. So it try to spread tasks on more cpu sockets and cpu cores To adding the consideration of power awareness, the patchset adds 2 kinds of scheduler policy: powersaving and balance. They will use runnable load util in scheduler balancing. The current scheduling is taken as performance policy. performance: the current scheduling behaviour, try to spread tasks on more CPU sockets or cores. performance oriented. powersaving: will pack tasks into few sched group until all LCPU in the group is full, power oriented. balance: will pack tasks into few sched group until group_capacity numbers CPU is full, balance between performance and powersaving. The incoming patches will enable powersaving/balance scheduling in CFS. Signed-off-by: Alex Shi --- kernel/sched/fair.c | 3 +++ kernel/sched/sched.h | 6 ++ 2 files changed, 9 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 350eb8d..2f98ffb 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6105,6 +6105,9 @@ static unsigned int get_rr_interval_fair(struct rq *rq, struct task_struct *task return rr_interval; } +/* The default scheduler policy is 'performance'. */ +int __read_mostly sched_balance_policy = SCHED_POLICY_PERFORMANCE; + /* * All the scheduling class methods: */ diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index ae3511e..7a19792 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -8,6 +8,12 @@ extern __read_mostly int scheduler_running; +#define SCHED_POLICY_PERFORMANCE (0x1) +#define SCHED_POLICY_POWERSAVING (0x2) +#define SCHED_POLICY_BALANCE (0x4) + +extern int __read_mostly sched_balance_policy; + /* * Convert user-nice values [ -20 ... 0 ... 19 ] * to static priority [ MAX_RT_PRIO..MAX_PRIO-1 ], -- 1.7.12 -- 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 v5 07/15] sched: add new sg/sd_lb_stats fields for incoming fork/exec/wake balancing
For power aware balancing, we care the sched domain/group's
utilizations more than their load weight. So add:
sd_lb_stats.sd_utils and sg_lb_stats.group_utils.
We want to know the sd capacity, so add:
sd_lb_stats.sd_capacity.
And want to know which group is busiest but still has free time to
handle more tasks, so add:
sd_lb_stats.group_leader.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b9a34ab..32b8a7b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4214,6 +4214,11 @@ struct sd_lb_stats {
unsigned int busiest_group_weight;
int group_imb; /* Is there imbalance in this sd */
+
+ /* Varibles of power awaring scheduling */
+ unsigned int sd_utils; /* sum utilizations of this domain */
+ unsigned long sd_capacity; /* capacity of this domain */
+ struct sched_group *group_leader; /* Group which relieves group_min */
};
/*
@@ -4229,6 +4234,7 @@ struct sg_lb_stats {
unsigned long group_weight;
int group_imb; /* Is there an imbalance in the group ? */
int group_has_capacity; /* Is there extra capacity in the group? */
+ unsigned int group_utils; /* sum utilizations of group */
};
/**
--
1.7.12
--
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 v5 08/15] sched: move sg/sd_lb_stats struct ahead
Power aware fork/exec/wake balancing needs both of structs in incoming
patches. So move ahead before it.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 101 ++--
1 file changed, 51 insertions(+), 50 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 32b8a7b..287582b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3312,6 +3312,57 @@ done:
}
/*
+ * sd_lb_stats - Structure to store the statistics of a sched_domain
+ * during load balancing.
+ */
+struct sd_lb_stats {
+ struct sched_group *busiest; /* Busiest group in this sd */
+ struct sched_group *this; /* Local group in this sd */
+ unsigned long total_load; /* Total load of all groups in sd */
+ unsigned long total_pwr; /* Total power of all groups in sd */
+ unsigned long avg_load;/* Average load across all groups in sd */
+
+ /** Statistics of this group */
+ unsigned long this_load;
+ unsigned long this_load_per_task;
+ unsigned long this_nr_running;
+ unsigned int this_has_capacity;
+ unsigned int this_idle_cpus;
+
+ /* Statistics of the busiest group */
+ unsigned int busiest_idle_cpus;
+ unsigned long max_load;
+ unsigned long busiest_load_per_task;
+ unsigned long busiest_nr_running;
+ unsigned long busiest_group_capacity;
+ unsigned int busiest_has_capacity;
+ unsigned int busiest_group_weight;
+
+ int group_imb; /* Is there imbalance in this sd */
+
+ /* Varibles of power awaring scheduling */
+ unsigned int sd_utils; /* sum utilizations of this domain */
+ unsigned long sd_capacity; /* capacity of this domain */
+ struct sched_group *group_leader; /* Group which relieves group_min */
+};
+
+/*
+ * sg_lb_stats - stats of a sched_group required for load_balancing
+ */
+struct sg_lb_stats {
+ unsigned long avg_load; /*Avg load across the CPUs of the group */
+ unsigned long group_load; /* Total load over the CPUs of the group */
+ unsigned long sum_nr_running; /* Nr tasks running in the group */
+ unsigned long sum_weighted_load; /* Weighted load of group's tasks */
+ unsigned long group_capacity;
+ unsigned long idle_cpus;
+ unsigned long group_weight;
+ int group_imb; /* Is there an imbalance in the group ? */
+ int group_has_capacity; /* Is there extra capacity in the group? */
+ unsigned int group_utils; /* sum utilizations of group */
+};
+
+/*
* sched_balance_self: balance the current task (running on cpu) in domains
* that have the 'flag' flag set. In practice, this is SD_BALANCE_FORK and
* SD_BALANCE_EXEC.
@@ -4186,56 +4237,6 @@ static unsigned long task_h_load(struct task_struct *p)
#endif
/** Helpers for find_busiest_group /
-/*
- * sd_lb_stats - Structure to store the statistics of a sched_domain
- * during load balancing.
- */
-struct sd_lb_stats {
- struct sched_group *busiest; /* Busiest group in this sd */
- struct sched_group *this; /* Local group in this sd */
- unsigned long total_load; /* Total load of all groups in sd */
- unsigned long total_pwr; /* Total power of all groups in sd */
- unsigned long avg_load;/* Average load across all groups in sd */
-
- /** Statistics of this group */
- unsigned long this_load;
- unsigned long this_load_per_task;
- unsigned long this_nr_running;
- unsigned long this_has_capacity;
- unsigned int this_idle_cpus;
-
- /* Statistics of the busiest group */
- unsigned int busiest_idle_cpus;
- unsigned long max_load;
- unsigned long busiest_load_per_task;
- unsigned long busiest_nr_running;
- unsigned long busiest_group_capacity;
- unsigned long busiest_has_capacity;
- unsigned int busiest_group_weight;
-
- int group_imb; /* Is there imbalance in this sd */
-
- /* Varibles of power awaring scheduling */
- unsigned int sd_utils; /* sum utilizations of this domain */
- unsigned long sd_capacity; /* capacity of this domain */
- struct sched_group *group_leader; /* Group which relieves group_min */
-};
-
-/*
- * sg_lb_stats - stats of a sched_group required for load_balancing
- */
-struct sg_lb_stats {
- unsigned long avg_load; /*Avg load across the CPUs of the group */
- unsigned long group_load; /* Total load over the CPUs of the group */
- unsigned long sum_nr_running; /* Nr tasks running in the group */
- unsigned long sum_weighted_load; /* Weighted load of group's tasks */
- unsigned long group_capacity;
- unsigned long idle_cpus;
- unsigned long group_weight;
- int group_imb; /* Is there an imbalance in the group ? */
- int group_has_capacity; /* Is there extra capacity in the group? */
-
[patch v5 09/15] sched: add power aware scheduling in fork/exec/wake
This patch add power aware scheduling in fork/exec/wake. It try to
select cpu from the busiest while still has utilization group. That's
will save power since it leaves more groups idle in system.
The trade off is adding a power aware statistics collection in group
seeking. But since the collection just happened in power scheduling
eligible condition, the worst case of hackbench testing just drops
about 2% with powersaving/balance policy. No clear change for
performance policy.
The main function in this patch is get_cpu_for_power_policy(), that
will try to get a idlest cpu from the busiest while still has
utilization group, if the system is using power aware policy and
has such group.
I had tried to use rq utilisation in this balancing, but since the
utilisation need much time to accumulate itself(345ms). It's bad for
any burst balancing. So I use instant rq utilisation -- nr_running.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 129 +---
1 file changed, 123 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 287582b..b172678 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3362,26 +3362,134 @@ struct sg_lb_stats {
unsigned int group_utils; /* sum utilizations of group */
};
+static inline int
+fix_small_capacity(struct sched_domain *sd, struct sched_group *group);
+
+/*
+ * Try to collect the task running number and capacity of the group.
+ */
+static void get_sg_power_stats(struct sched_group *group,
+ struct sched_domain *sd, struct sg_lb_stats *sgs)
+{
+ int i;
+
+ for_each_cpu(i, sched_group_cpus(group)) {
+ struct rq *rq = cpu_rq(i);
+
+ sgs->group_utils += rq->nr_running;
+ }
+
+ sgs->group_capacity = DIV_ROUND_CLOSEST(group->sgp->power,
+ SCHED_POWER_SCALE);
+ if (!sgs->group_capacity)
+ sgs->group_capacity = fix_small_capacity(sd, group);
+ sgs->group_weight = group->group_weight;
+}
+
+/*
+ * Try to collect the task running number and capacity of the domain.
+ */
+static void get_sd_power_stats(struct sched_domain *sd,
+ struct task_struct *p, struct sd_lb_stats *sds)
+{
+ struct sched_group *group;
+ struct sg_lb_stats sgs;
+ int sd_min_delta = INT_MAX;
+ int cpu = task_cpu(p);
+
+ group = sd->groups;
+ do {
+ long g_delta;
+ unsigned long threshold;
+
+ if (!cpumask_test_cpu(cpu, sched_group_mask(group)))
+ continue;
+
+ memset(, 0, sizeof(sgs));
+ get_sg_power_stats(group, sd, );
+
+ if (sched_balance_policy == SCHED_POLICY_POWERSAVING)
+ threshold = sgs.group_weight;
+ else
+ threshold = sgs.group_capacity;
+
+ g_delta = threshold - sgs.group_utils;
+
+ if (g_delta > 0 && g_delta < sd_min_delta) {
+ sd_min_delta = g_delta;
+ sds->group_leader = group;
+ }
+
+ sds->sd_utils += sgs.group_utils;
+ sds->total_pwr += group->sgp->power;
+ } while (group = group->next, group != sd->groups);
+
+ sds->sd_capacity = DIV_ROUND_CLOSEST(sds->total_pwr,
+ SCHED_POWER_SCALE);
+}
+
+/*
+ * Execute power policy if this domain is not full.
+ */
+static inline int get_sd_sched_balance_policy(struct sched_domain *sd,
+ int cpu, struct task_struct *p, struct sd_lb_stats *sds)
+{
+ unsigned long threshold;
+
+ if (sched_balance_policy == SCHED_POLICY_PERFORMANCE)
+ return SCHED_POLICY_PERFORMANCE;
+
+ memset(sds, 0, sizeof(*sds));
+ get_sd_power_stats(sd, p, sds);
+
+ if (sched_balance_policy == SCHED_POLICY_POWERSAVING)
+ threshold = sd->span_weight;
+ else
+ threshold = sds->sd_capacity;
+
+ /* still can hold one more task in this domain */
+ if (sds->sd_utils < threshold)
+ return sched_balance_policy;
+
+ return SCHED_POLICY_PERFORMANCE;
+}
+
+/*
+ * If power policy is eligible for this domain, and it has task allowed cpu.
+ * we will select CPU from this domain.
+ */
+static int get_cpu_for_power_policy(struct sched_domain *sd, int cpu,
+ struct task_struct *p, struct sd_lb_stats *sds)
+{
+ int policy;
+ int new_cpu = -1;
+
+ policy = get_sd_sched_balance_policy(sd, cpu, p, sds);
+ if (policy != SCHED_POLICY_PERFORMANCE && sds->group_leader)
+ new_cpu = find_idlest_cpu(sds->group_leader, p, cpu);
+
+ return new_cpu;
+}
+
/*
- * sched_balance_self: balance the current task (running on cpu) in domains
+ * select_task_rq_fair: balance the current task (running on cpu) in domains
* that have the 'flag'
[patch v5 03/15] Revert "sched: Introduce temporary FAIR_GROUP_SCHED dependency for load-tracking"
Remove CONFIG_FAIR_GROUP_SCHED that covers the runnable info, then
we can use runnable load variables.
Signed-off-by: Alex Shi
---
include/linux/sched.h | 8 +---
kernel/sched/core.c | 7 +--
kernel/sched/fair.c | 13 ++---
kernel/sched/sched.h | 9 +
4 files changed, 5 insertions(+), 32 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index f283d3d..66b05e1 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1195,13 +1195,7 @@ struct sched_entity {
/* rq "owned" by this entity/group: */
struct cfs_rq *my_q;
#endif
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
- /* Per-entity load-tracking */
+#ifdef CONFIG_SMP
struct sched_avgavg;
#endif
};
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7292965..0bd9d5f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1551,12 +1551,7 @@ static void __sched_fork(struct task_struct *p)
p->se.vruntime = 0;
INIT_LIST_HEAD(>se.group_node);
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+#ifdef CONFIG_SMP
p->se.avg.runnable_avg_period = 0;
p->se.avg.runnable_avg_sum = 0;
p->se.avg.decay_count = 0;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 171790c..350eb8d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1109,8 +1109,7 @@ static inline void update_cfs_shares(struct cfs_rq
*cfs_rq)
}
#endif /* CONFIG_FAIR_GROUP_SCHED */
-/* Only depends on SMP, FAIR_GROUP_SCHED may be removed when useful in lb */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+#ifdef CONFIG_SMP
/*
* We choose a half-life close to 1 scheduling period.
* Note: The tables below are dependent on this value.
@@ -3410,12 +3409,6 @@ unlock:
}
/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#ifdef CONFIG_FAIR_GROUP_SCHED
-/*
* Called immediately before a task is migrated to a new cpu; task_cpu(p) and
* cfs_rq_of(p) references at time of call are still valid and identify the
* previous cpu. However, the caller only guarantees p->pi_lock is held; no
@@ -3438,7 +3431,6 @@ migrate_task_rq_fair(struct task_struct *p, int next_cpu)
atomic64_add(se->avg.load_avg_contrib, _rq->removed_load);
}
}
-#endif
#endif /* CONFIG_SMP */
static unsigned long
@@ -6130,9 +6122,8 @@ const struct sched_class fair_sched_class = {
#ifdef CONFIG_SMP
.select_task_rq = select_task_rq_fair,
-#ifdef CONFIG_FAIR_GROUP_SCHED
.migrate_task_rq= migrate_task_rq_fair,
-#endif
+
.rq_online = rq_online_fair,
.rq_offline = rq_offline_fair,
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index fc88644..ae3511e 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -225,12 +225,6 @@ struct cfs_rq {
#endif
#ifdef CONFIG_SMP
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#ifdef CONFIG_FAIR_GROUP_SCHED
/*
* CFS Load tracking
* Under CFS, load is tracked on a per-entity basis and aggregated up.
@@ -240,8 +234,7 @@ struct cfs_rq {
u64 runnable_load_avg, blocked_load_avg;
atomic64_t decay_counter, removed_load;
u64 last_decay;
-#endif /* CONFIG_FAIR_GROUP_SCHED */
-/* These always depend on CONFIG_FAIR_GROUP_SCHED */
+
#ifdef CONFIG_FAIR_GROUP_SCHED
u32 tg_runnable_contrib;
u64 tg_load_contrib;
--
1.7.12
--
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 v5 12/15] sched: pull all tasks from source group
In power balance, we hope some sched groups are fully empty to save
CPU power of them. So, we want to move any tasks from them.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0047856..f3abb83 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5125,7 +5125,9 @@ static struct rq *find_busiest_queue(struct lb_env *env,
* When comparing with imbalance, use weighted_cpuload()
* which is not scaled with the cpu power.
*/
- if (capacity && rq->nr_running == 1 && wl > env->imbalance)
+ if (rq->nr_running == 0 ||
+ (!env->power_lb && capacity &&
+ rq->nr_running == 1 && wl > env->imbalance))
continue;
/*
@@ -5229,7 +5231,8 @@ redo:
ld_moved = 0;
lb_iterations = 1;
- if (busiest->nr_running > 1) {
+ if (busiest->nr_running > 1 ||
+ (busiest->nr_running == 1 && env.power_lb)) {
/*
* Attempt to move tasks. If find_busiest_group has found
* an imbalance but busiest->nr_running <= 1, the group is
--
1.7.12
--
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 v5 14/15] sched: power aware load balance
This patch enabled the power aware consideration in load balance.
As mentioned in the power aware scheduler proposal, Power aware
scheduling has 2 assumptions:
1, race to idle is helpful for power saving
2, less active sched_groups will reduce power consumption
The first assumption make performance policy take over scheduling when
any scheduler group is busy.
The second assumption make power aware scheduling try to pack disperse
tasks into fewer groups.
The enabling logical summary here:
1, Collect power aware scheduler statistics during performance load
balance statistics collection.
2, If the balance cpu is eligible for power load balance, just do it
and forget performance load balance. If the domain is suitable for
power balance, but the cpu is inappropriate(idle or full), stop both
power/performance balance in this domain. If using performance balance
or any group is busy, do performance balance.
Above logical is mainly implemented in update_sd_lb_power_stats(). It
decides if a domain is suitable for power aware scheduling. If so,
it will fill the dst group and source group accordingly.
This patch reuse some of Suresh's power saving load balance code.
A test can show the effort on different policy:
for ((i = 0; i < I; i++)) ; do while true; do :; done & done
On my SNB laptop with 4core* HT: the data is Watts
powersaving balance performance
i = 2 40 54 54
i = 4 57 64* 68
i = 8 68 68 68
Note:
When i = 4 with balance policy, the power may change in 57~68Watt,
since the HT capacity and core capacity are both 1.
on SNB EP machine with 2 sockets * 8 cores * HT:
powersaving balance performance
i = 4 190 201 238
i = 8 205 241 268
i = 16 271 348 376
If system has few continued tasks, use power policy can get
the performance/power gain. Like sysbench fileio randrw test with 16
thread on the SNB EP box,
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 129 ++--
1 file changed, 126 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ffdf35d..3b1e9a6 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3344,6 +3344,10 @@ struct sd_lb_stats {
unsigned int sd_utils; /* sum utilizations of this domain */
unsigned long sd_capacity; /* capacity of this domain */
struct sched_group *group_leader; /* Group which relieves group_min */
+ struct sched_group *group_min; /* Least loaded group in sd */
+ unsigned long min_load_per_task; /* load_per_task in group_min */
+ unsigned int leader_util; /* sum utilizations of group_leader */
+ unsigned int min_util; /* sum utilizations of group_min */
};
/*
@@ -4412,6 +4416,105 @@ static unsigned long task_h_load(struct task_struct *p)
/** Helpers for find_busiest_group /
/**
+ * init_sd_lb_power_stats - Initialize power savings statistics for
+ * the given sched_domain, during load balancing.
+ *
+ * @env: The load balancing environment.
+ * @sds: Variable containing the statistics for sd.
+ */
+static inline void init_sd_lb_power_stats(struct lb_env *env,
+ struct sd_lb_stats *sds)
+{
+ if (sched_balance_policy == SCHED_POLICY_PERFORMANCE ||
+ env->idle == CPU_NOT_IDLE) {
+ env->power_lb = 0;
+ env->perf_lb = 1;
+ return;
+ }
+ env->perf_lb = 0;
+ env->power_lb = 1;
+ sds->min_util = UINT_MAX;
+ sds->leader_util = 0;
+}
+
+/**
+ * update_sd_lb_power_stats - Update the power saving stats for a
+ * sched_domain while performing load balancing.
+ *
+ * @env: The load balancing environment.
+ * @group: sched_group belonging to the sched_domain under consideration.
+ * @sds: Variable containing the statistics of the sched_domain
+ * @local_group: Does group contain the CPU for which we're performing
+ * load balancing?
+ * @sgs: Variable containing the statistics of the group.
+ */
+static inline void update_sd_lb_power_stats(struct lb_env *env,
+ struct sched_group *group, struct sd_lb_stats *sds,
+ int local_group, struct sg_lb_stats *sgs)
+{
+ unsigned long threshold, threshold_util;
+
+ if (env->perf_lb)
+ return;
+
+ if (sched_balance_policy == SCHED_POLICY_POWERSAVING)
+ threshold = sgs->group_weight;
+ else
+ threshold = sgs->group_capacity;
+ threshold_util = threshold * FULL_UTIL;
+
+ /*
+* If the local group is idle or full loaded
+* no need to do power savings balance at this domain
+*/
+ if (local_group && (!sgs->sum_nr_running ||
+
[patch v5 15/15] sched: lazy power balance
When active task number in sched domain waves around the power friendly
scheduling creteria, scheduling will thresh between the power friendly
balance and performance balance, bring unnecessary task migration.
The typical benchmark is 'make -j x'.
To remove such issue, introduce a u64 perf_lb_record variable to record
performance load balance history. If there is no performance LB for
continuing 32 times load balancing, or no LB for 8 times max_interval ms,
or only 4 times performance LB in last 64 times load balancing, then we
accept a power friendly LB. Otherwise, give up this time power friendly
LB chance, do nothing.
With this patch, the worst case for power scheduling -- kbuild, gets
similar performance/power value among different policy.
BTW, the lazy balance shows the performance gain when j is up to 32.
On my SNB EP 2 sockets machine with 8 cores * HT: 'make -j x' results:
powersaving balance performance
x = 1175.603 /417 13 175.220 /416 13176.073 /407 13
x = 2192.215 /218 23 194.522 /202 25217.393 /200 23
x = 4205.226 /124 39 208.823 /114 42230.425 /105 41
x = 8236.369 /71 59 249.005 /65 61 257.661 /62 62
x = 16 283.842 /48 73 307.465 /40 81 309.336 /39 82
x = 32 325.197 /32 96 333.503 /32 93 336.138 /32 92
data explains: 175.603 /417 13
175.603: avagerage Watts
417: seconds(compile time)
13: scaled performance/power = 100 / seconds / watts
Signed-off-by: Alex Shi
---
include/linux/sched.h | 1 +
kernel/sched/fair.c | 68 ++-
2 files changed, 57 insertions(+), 12 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 66b05e1..5051990 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -941,6 +941,7 @@ struct sched_domain {
unsigned long last_balance; /* init to jiffies. units in jiffies */
unsigned int balance_interval; /* initialise to 1. units in ms. */
unsigned int nr_balance_failed; /* initialise to 0 */
+ u64 perf_lb_record; /* performance balance record */
u64 last_update;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3b1e9a6..f6ae655 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4514,6 +4514,60 @@ static inline void update_sd_lb_power_stats(struct
lb_env *env,
}
}
+#define PERF_LB_HH_MASK0xULL
+#define PERF_LB_LH_MASK0xULL
+
+/**
+ * need_perf_balance - Check if the performance load balance needed
+ * in the sched_domain.
+ *
+ * @env: The load balancing environment.
+ * @sds: Variable containing the statistics of the sched_domain
+ */
+static int need_perf_balance(struct lb_env *env, struct sd_lb_stats *sds)
+{
+ env->sd->perf_lb_record <<= 1;
+
+ if (env->perf_lb) {
+ env->sd->perf_lb_record |= 0x1;
+ return 1;
+ }
+
+ /*
+* The situation isn't eligible for performance balance. If this_cpu
+* is not eligible or the timing is not suitable for lazy powersaving
+* balance, we will stop both powersaving and performance balance.
+*/
+ if (env->power_lb && sds->this == sds->group_leader
+ && sds->group_leader != sds->group_min) {
+ int interval;
+
+ /* powersaving balance interval set as 8 * max_interval */
+ interval = msecs_to_jiffies(8 * env->sd->max_interval);
+ if (time_after(jiffies, env->sd->last_balance + interval))
+ env->sd->perf_lb_record = 0;
+
+ /*
+* A eligible timing is no performance balance in last 32
+* balance and performance balance is no more than 4 times
+* in last 64 balance, or no balance in powersaving interval
+* time.
+*/
+ if ((hweight64(env->sd->perf_lb_record & PERF_LB_HH_MASK) <= 4)
+ && !(env->sd->perf_lb_record & PERF_LB_LH_MASK)) {
+
+ env->imbalance = sds->min_load_per_task;
+ return 0;
+ }
+
+ }
+
+ /* give up this time power balancing, do nothing */
+ env->power_lb = 0;
+ sds->group_min = NULL;
+ return 0;
+}
+
/**
* get_sd_load_idx - Obtain the load index for a given sched domain.
* @sd: The sched_domain whose load_idx is to be obtained.
@@ -5137,18 +5191,8 @@ find_busiest_group(struct lb_env *env, int *balance)
*/
update_sd_lb_stats(env, balance, );
- if (!env->perf_lb && !env->power_lb)
- return NULL;
-
- if (env->power_lb) {
- if (sds.this == sds.group_leader &&
- sds.group_leader != sds.group_min) {
-
[patch v5 13/15] sched: no balance for prefer_sibling in power scheduling
In power aware scheduling, we don't want to balance 'prefer_sibling'
groups just because local group has capacity.
If the local group has no tasks at the time, that is the power
balance hope so.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f3abb83..ffdf35d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4782,8 +4782,12 @@ static inline void update_sd_lb_stats(struct lb_env *env,
* extra check prevents the case where you always pull from the
* heaviest group when it is already under-utilized (possible
* with a large weight task outweighs the tasks on the system).
+*
+* In power aware scheduling, we don't care load weight and
+* want not to pull tasks just because local group has capacity.
*/
- if (prefer_sibling && !local_group && sds->this_has_capacity)
+ if (prefer_sibling && !local_group && sds->this_has_capacity
+ && env->perf_lb)
sgs.group_capacity = min(sgs.group_capacity, 1UL);
if (local_group) {
--
1.7.12
--
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 v5 11/15] sched: add power/performance balance allow flag
If a sched domain is idle enough for regular power balance, power_lb
will be set, perf_lb will be clean. If a sched domain is busy,
their value will be set oppositely.
If the domain is suitable for power balance, but balance should not
be down by this cpu(this cpu is already idle or full), both of perf_lb
and power_lb are cleared to wait a suitable cpu to do power balance.
That mean no any balance, neither power balance nor performance balance
will be done on this cpu.
Above logical will be implemented by incoming patches.
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2e8131d..0047856 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4053,6 +4053,8 @@ struct lb_env {
unsigned intloop;
unsigned intloop_break;
unsigned intloop_max;
+ int power_lb; /* if power balance needed */
+ int perf_lb; /* if performance balance needed */
};
/*
@@ -5195,6 +5197,8 @@ static int load_balance(int this_cpu, struct rq *this_rq,
.idle = idle,
.loop_break = sched_nr_migrate_break,
.cpus = cpus,
+ .power_lb = 0,
+ .perf_lb= 1,
};
cpumask_copy(cpus, cpu_active_mask);
--
1.7.12
--
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 v5 02/15] sched: set initial load avg of new forked task
New task has no runnable sum at its first runnable time, so its
runnable load is zero. That makes burst forking balancing just select
few idle cpus to assign tasks if we engage runnable load in balancing.
Set initial load avg of new forked task as its load weight to resolve
this issue.
Signed-off-by: Alex Shi
Reviewed-by: Preeti U Murthy
---
include/linux/sched.h | 1 +
kernel/sched/core.c | 2 +-
kernel/sched/fair.c | 11 +--
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index d211247..f283d3d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1069,6 +1069,7 @@ struct sched_domain;
#else
#define ENQUEUE_WAKING 0
#endif
+#define ENQUEUE_NEWTASK8
#define DEQUEUE_SLEEP 1
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1743746..7292965 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1706,7 +1706,7 @@ void wake_up_new_task(struct task_struct *p)
#endif
rq = __task_rq_lock(p);
- activate_task(rq, p, 0);
+ activate_task(rq, p, ENQUEUE_NEWTASK);
p->on_rq = 1;
trace_sched_wakeup_new(p, true);
check_preempt_curr(rq, p, WF_FORK);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 81fa536..171790c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1503,8 +1503,9 @@ static inline void update_rq_runnable_avg(struct rq *rq,
int runnable)
/* Add the load generated by se into cfs_rq's child load-average */
static inline void enqueue_entity_load_avg(struct cfs_rq *cfs_rq,
struct sched_entity *se,
- int wakeup)
+ int flags)
{
+ int wakeup = flags & ENQUEUE_WAKEUP;
/*
* We track migrations using entity decay_count <= 0, on a wake-up
* migration we use a negative decay count to track the remote decays
@@ -1538,6 +1539,12 @@ static inline void enqueue_entity_load_avg(struct cfs_rq
*cfs_rq,
update_entity_load_avg(se, 0);
}
+ /*
+* set the initial load avg of new task same as its load
+* in order to avoid brust fork make few cpu too heavier
+*/
+ if (flags & ENQUEUE_NEWTASK)
+ se->avg.load_avg_contrib = se->load.weight;
cfs_rq->runnable_load_avg += se->avg.load_avg_contrib;
/* we force update consideration on load-balancer moves */
update_cfs_rq_blocked_load(cfs_rq, !wakeup);
@@ -1701,7 +1708,7 @@ enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity
*se, int flags)
* Update run-time statistics of the 'current'.
*/
update_curr(cfs_rq);
- enqueue_entity_load_avg(cfs_rq, se, flags & ENQUEUE_WAKEUP);
+ enqueue_entity_load_avg(cfs_rq, se, flags);
account_entity_enqueue(cfs_rq, se);
update_cfs_shares(cfs_rq);
--
1.7.12
--
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 v5 10/15] sched: packing transitory tasks in wake/exec power balancing
If the waked/execed task is transitory enough, it will has a chance to be
packed into a cpu which is busy but still has time to care it.
For powersaving policy, only the history util < 25% task has chance to
be packed, and for balance policy, only histroy util < 12.5% has chance.
If there is no cpu eligible to handle it, will use a idlest cpu in
leader group.
Morten Rasmussen catch a type bug and suggest using different criteria
for different policy, thanks!
Inspired-by: Vincent Guittot
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 66 -
1 file changed, 60 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b172678..2e8131d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3455,19 +3455,72 @@ static inline int get_sd_sched_balance_policy(struct
sched_domain *sd,
}
/*
+ * find_leader_cpu - find the busiest but still has enough leisure time cpu
+ * among the cpus in group.
+ */
+static int
+find_leader_cpu(struct sched_group *group, struct task_struct *p, int this_cpu,
+ int policy)
+{
+ /* percentage of the task's util */
+ unsigned putil = p->se.avg.runnable_avg_sum * 100
+ / (p->se.avg.runnable_avg_period + 1);
+
+ struct rq *rq = cpu_rq(this_cpu);
+ int nr_running = rq->nr_running > 0 ? rq->nr_running : 1;
+ int vacancy, min_vacancy = INT_MAX, max_util;
+ int leader_cpu = -1;
+ int i;
+
+ if (policy == SCHED_POLICY_POWERSAVING)
+ max_util = FULL_UTIL;
+ else
+ /* maximum allowable util is 60% */
+ max_util = 60;
+
+ /* bias toward local cpu */
+ if (cpumask_test_cpu(this_cpu, tsk_cpus_allowed(p)) &&
+ max_util - (rq->util * nr_running + (putil << 2)) > 0)
+ return this_cpu;
+
+ /* Traverse only the allowed CPUs */
+ for_each_cpu_and(i, sched_group_cpus(group), tsk_cpus_allowed(p)) {
+ if (i == this_cpu)
+ continue;
+
+ rq = cpu_rq(i);
+ nr_running = rq->nr_running > 0 ? rq->nr_running : 1;
+
+ /* only light task allowed, like putil < 25% for powersaving */
+ vacancy = max_util - (rq->util * nr_running + (putil << 2));
+
+ if (vacancy > 0 && vacancy < min_vacancy) {
+ min_vacancy = vacancy;
+ leader_cpu = i;
+ }
+ }
+ return leader_cpu;
+}
+
+/*
* If power policy is eligible for this domain, and it has task allowed cpu.
* we will select CPU from this domain.
*/
static int get_cpu_for_power_policy(struct sched_domain *sd, int cpu,
- struct task_struct *p, struct sd_lb_stats *sds)
+ struct task_struct *p, struct sd_lb_stats *sds, int fork)
{
int policy;
int new_cpu = -1;
policy = get_sd_sched_balance_policy(sd, cpu, p, sds);
- if (policy != SCHED_POLICY_PERFORMANCE && sds->group_leader)
- new_cpu = find_idlest_cpu(sds->group_leader, p, cpu);
-
+ if (policy != SCHED_POLICY_PERFORMANCE && sds->group_leader) {
+ if (!fork)
+ new_cpu = find_leader_cpu(sds->group_leader,
+ p, cpu, policy);
+ /* for fork balancing and a little busy task */
+ if (new_cpu == -1)
+ new_cpu = find_idlest_cpu(sds->group_leader, p, cpu);
+ }
return new_cpu;
}
@@ -3518,14 +3571,15 @@ select_task_rq_fair(struct task_struct *p, int sd_flag,
int flags)
if (tmp->flags & sd_flag) {
sd = tmp;
- new_cpu = get_cpu_for_power_policy(sd, cpu, p, );
+ new_cpu = get_cpu_for_power_policy(sd, cpu, p, ,
+ flags & SD_BALANCE_FORK);
if (new_cpu != -1)
goto unlock;
}
}
if (affine_sd) {
- new_cpu = get_cpu_for_power_policy(affine_sd, cpu, p, );
+ new_cpu = get_cpu_for_power_policy(affine_sd, cpu, p, , 0);
if (new_cpu != -1)
goto unlock;
--
1.7.12
--
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 v5 0/15] power aware scheduling
Since the simplification of fork/exec/wake balancing has much arguments, I removed that part in the patch set. This patch set implement/consummate the rough power aware scheduling proposal: https://lkml.org/lkml/2012/8/13/139. It defines 2 new power aware policy 'balance' and 'powersaving', then try to pack tasks on each sched groups level according the different scheduler policy. That can save much power when task number in system is no more than LCPU number. As mentioned in the power aware scheduling proposal, Power aware scheduling has 2 assumptions: 1, race to idle is helpful for power saving 2, less active sched groups will reduce cpu power consumption The first assumption make performance policy take over scheduling when any group is busy. The second assumption make power aware scheduling try to pack disperse tasks into fewer groups. Like sched numa, power aware scheduling is also a kind of cpu locality oriented scheduling, so it is natural compatible with sched numa. Since the patch can perfect pack tasks into fewer groups, I just show some performance/power testing data here: = $for ((i = 0; i < I; i++)) ; do while true; do :; done & done On my SNB laptop with 4core* HT: the data is avg Watts powersaving balance performance i = 2 40 54 54 i = 4 57 64* 68 i = 8 68 68 68 Note: When i = 4 with balance policy, the power may change in 57~68Watt, since the HT capacity and core capacity are both 1. on SNB EP machine with 2 sockets * 8 cores * HT: powersaving balance performance i = 4 190 201 238 i = 8 205 241 268 i = 16 271 348 376 bltk-game with openarena, the data is avg Watts powersaving balance performance wsm laptop 22.9 23.8 24.4 snb laptop 20.2 20.5 20.7 tasks number keep waving benchmark, 'make -j x vmlinux' on my SNB EP 2 sockets machine with 8 cores * HT: powersaving balanceperformance x = 1175.603 /417 13 175.220 /416 13176.073 /407 13 x = 2192.215 /218 23 194.522 /202 25217.393 /200 23 x = 4205.226 /124 39 208.823 /114 42230.425 /105 41 x = 8236.369 /71 59 249.005 /65 61 257.661 /62 62 x = 16 283.842 /48 73 307.465 /40 81 309.336 /39 82 x = 32 325.197 /32 96 333.503 /32 93 336.138 /32 92 data explains: 175.603 /417 13 175.603: average Watts 417: seconds(compile time) 13: scaled performance/power = 100 / seconds / watts Another testing of parallel compress with pigz on Linus' git tree. results show we get much better performance/power with powersaving and balance policy: testing command: #pigz -k -c -p$x -r linux* &> /dev/null On a NHM EP box powersaving balance performance x = 4166.516 /88 68 170.515 /82 71 165.283 /103 58 x = 8173.654 /61 94 177.693 /60 93 172.31 /76 76 On a 2 sockets SNB EP box. powersaving balance performance x = 4190.995 /149 35 200.6 /129 38 208.561 /135 35 x = 8197.969 /108 46 208.885 /103 46213.96 /108 43 x = 16 205.163 /76 64 212.144 /91 51 229.287 /97 44 data format is: 166.516 /88 68 166.516: average Watts 88: seconds(compress time) 68: scaled performance/power = 100 / time / power Some performance testing results: - Tested benchmarks: kbuild, specjbb2005, oltp, tbench, aim9, hackbench, fileio-cfq of sysbench, dbench, aiostress, multhreads loopback netperf. on my core2, nhm, wsm, snb, platforms. no clear performance change found on 'performance' policy. Tested balance/powersaving policy with above benchmarks, a, specjbb2005 drop 5~7% on both of policy whenever with openjdk or jrockit. b, hackbench drops 30+% with powersaving policy on snb 4 sockets platforms. Others has no clear change. test result from Mike Galbraith: With aim7 compute on 4 node 40 core box, I see stable throughput improvement at tasks = nr_cores and below w. balance and powersaving. 3.8.0-performance 3.8.0-balance 3.8.0-powersaving Tasksjobs/min/task jobs/min/task jobs/min/task 1 432.8571 433.4764 433.1665 5 480.1902 510.9612 497.5369 10 429.1785 533.4507 518.3918 20 424.3697 529.7203 528.7958 40 419.0871 500.8264 517.0648 No deltas after that. There were also no deltas between patched kernel using performance policy and virgin source.
Re: [PATCH v3 1/1] tools/power x86_energy_perf_policy: fix cpuid for i686
Hi Benson, checkpatch.pl doesn't love this syntax: ERROR: spaces required around that ':' (ctx:ExV) #113: FILE: tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.c:142: + :"+a" (_eax), "=S" (_ebx), "=c" (_ecx), "=d" (_edx) ^ ERROR: spaces required around that ':' (ctx:ExV) #115: FILE: tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.c:144: + :"edi" /* clobbers: we hit edi directly */); ^ ERROR: trailing statements should be on next line #116: FILE: tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.c:145: + if (eax) *eax = _eax; ERROR: trailing statements should be on next line #117: FILE: tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.c:146: + if (ebx) *ebx = _ebx; ERROR: trailing statements should be on next line #118: FILE: tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.c:147: + if (ecx) *ecx = _ecx; ERROR: trailing statements should be on next line #119: FILE: tools/power/x86/x86_energy_perf_policy/x86_energy_perf_policy.c:148: + if (edx) *edx = _edx; total: 6 errors, 2 warnings, 57 lines checked /home/lenb/Documents/epp.eml has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Commit Body is: -- tools/power x86_energy_perf_policy: fix cpuid for i686 -- 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: Stupid user with user-space questions, matrix LED driving with user space code only.
On Sun, 2013-02-17 at 18:05 -0800, Greg KH wrote: > On Sun, Feb 17, 2013 at 02:37:24PM +, Jonathan Andrews wrote: > > From a user perspective it seems a bit crap to have to change the kernel > > if you have a workload that preemption is harmful to. > > In the case of something like the Raspberry Pi changing the kernel if > > the distribution has not done the work for me sounds like real effort. > > The kernel is tied to binary obscurity from broadcom... To build I need > > a working cross compiler, toolchain, kernel sources, Pi specific patches > > then to get everything in the correct place on an SD card containing two > > filesystems. Its possible but its not going to "just work" at my skill > > level > > As you can not boot a kernel.org kernel on the RPI platform just yet, > there's very little that the kernel.org community can do here to help > you out. Somebody could stick in the code to enable/disable preemption at runtime on PREEMPT compiled kernels :-) - Then all I have to do is wait for it to filter down to the Raspian kernel maintainers, i'm patient ;-) ? In all seriousness I assume preemption has a timer and an interrupt vector, cant the timer simply be enabled/disabled leaving just the kernel call mechanism untouched. IE a "preemption" kernel that is now not preempting .. OK, OK - I have many other egg sucking suggestions but am I the only one who wants the functionality ? Seems a half step to add all this wizzy real-time code to the kernel then stop users doing real-time in user space by allowing the schedular to yield during what a user wishes to be a citical section (from a timing point of view not the atomic point of view). What about a yield alignment mechanism for user space. IE the process calls the kernel with a request "schedule me first after a yeild" - then the process at least has whatever the timer granularity is to do something timing critical... add a flag to ignore or defer interrupts and you have a semi 'hard-realtime' behaviour for user space, allowing user space to grab small chunks of real time. Yes a nasty looking facility for SMP intel servers but really useful for embedded. > I suggest you go take this up with the developers whom you got > this specific kernel build from, there's nothing we can do here about > it. I suspected it was not going to be simple. As I suspect my feature request is not that simple but if you don't ask Thanks, Jon -- 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: manual merge of the arm-soc tree with the input tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
drivers/input/keyboard/tegra-kbc.c between commit 9eee07d39fa6 ("Input:
tegra-kbc - require CONFIG_OF, remove platform data") from the input tree
and commit 61fd290d213e ("ARM: tegra: migrate to new clock code") from
the arm-soc 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 drivers/input/keyboard/tegra-kbc.c
index d89e7d39,54ac1dc..000
--- a/drivers/input/keyboard/tegra-kbc.c
+++ b/drivers/input/keyboard/tegra-kbc.c
@@@ -29,16 -29,9 +29,16 @@@
#include
#include
#include
-#include
+#include
- #include
+ #include
+#define KBC_MAX_GPIO 24
+#define KBC_MAX_KPENT 8
+
+#define KBC_MAX_ROW 16
+#define KBC_MAX_COL 8
+#define KBC_MAX_KEY (KBC_MAX_ROW * KBC_MAX_COL)
+
#define KBC_MAX_DEBOUNCE_CNT 0x3ffu
/* KBC row scan time and delay for beginning the row scan. */
pgpgmBBSnu_kS.pgp
Description: PGP signature
cpuidle sizes (Re: [PATCH 14/16] intel_idle: remove use and definition of MWAIT_MAX_NUM_CSTATES)
On 02/12/2013 05:43 PM, Daniel Lezcano wrote:
> On 02/12/2013 12:46 AM, Len Brown wrote:
>> On 02/11/2013 03:53 AM, Daniel Lezcano wrote:
>>> On 02/09/2013 02:08 AM, Len Brown wrote:
>>
The reason to change is that intel_idle will soon be able
to export more than the 8 "major" states supported by MWAIT.
When we hit that limit, it is important to know
where the limit comes from.
>>>
>>> Does it mean CPUIDLE_STATE_MAX may increase in a near future ?
>>
>> Yes, perhaps to 10.
>> Let me know if you anticipate issues with doing that.
>
> No, I don't see any issue so far. Maybe the array state is increasing
> more and more, so for most architecture it is a waste of memory, but
> anyway ...
aking a quick look at data structure sizes...
struct cpuidle_device{} is allocated per cpu --
so if we have a lot of cpus, that gets multiplied out.
But it doesn't grow much with growing CPUIDLE_STATE_MAX:
cpuidle_state_usage states_usage[CPUIDLE_STATE_MAX];
we just shrunk to 24 bytes from 32 bytes/entry.
(and 240 < 256, so we're still shrinking:-)
plus it contains cpuidle_state_kobj *kobjs[CPUIDLE_STATE_MAX];
which is a set of pointers per cpu - so with 8-byte
pointers, that would be 64->80 bytes/cpu.
The other sizes that vary with CPUIDLE_STATE_MAX
seem to be static allocations per driver --
and so they don't grow much. Did I miss something?
thanks,
Len Brown, Intel Open Source Technology Center
ps. I can easily offer an arch-specific CPUIDLE_STATE_MAX over-ride
if you want to squeeze bytes per-arch.
--
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] net: fix functions and variables related to netns_ipvs->sysctl_sync_qlen_max
On Fri, Feb 15, 2013 at 11:39:34PM +0200, Julian Anastasov wrote: > > Hello, > > On Thu, 14 Feb 2013, Andrew Morton wrote: > > > On Thu, 7 Feb 2013 10:40:26 +0200 (EET) > > Julian Anastasov wrote: > > > > > > Another question about the sysctl_sync_qlen_max: > > > > This variable is assigned as: > > > > > > > > ipvs->sysctl_sync_qlen_max = nr_free_buffer_pages() / 32; > > > > > > > > The function nr_free_buffer_pages actually means: counts of pages > > > > which are beyond high watermark within ZONE_DMA and ZONE_NORMAL. > > > > > > > > is it ok to be called here? Some people misused this function because > > > > the function name was misleading them. I am sorry I am totally not > > > > familiar with the ipvs code, so I am just asking you about > > > > this. > > > > > > Using nr_free_buffer_pages should be fine here. > > > We are using it as rough estimation for the number of sync > > > buffers we can use in NORMAL zones. We are using dev->mtu > > > for such buffers, so it can take a PAGE_SIZE for a buffer. > > > We are not interested in HIGHMEM size. high watermarks > > > should have negliable effect. I'm even not sure whether > > > we need to clamp it for systems with TBs of memory. > > > > Using nr_free_buffer_pages() is good-enough-for-now. There are > > questions around the name of this thing and its exact functionality and > > whether callers are using it appropriately. But if anything is changed > > there, it will be as part of kernel-wide sweep. > > > > One thing to bear in mind is memory hot[un]plug. Anything which was > > sized using nr_free_buffer_pages() (or similar) may become > > inappropriately sized if memory is added or removed. So any site which > > uses nr_free_buffer_pages() really should be associated with a hotplug > > handler and a great pile of code to resize the structure at runtime. > > It's pretty ugly stuff :( I suspect it usually Just Doesn't Matter. > > I'll try to think on this hotplug problem > and also on the si_meminfo usage in net/netfilter/ipvs/ip_vs_ctl.c > which is quite wrong for systems with HIGHMEM, may be > we need there a free+reclaimable+file function for > NORMAL zone. > > > Redarding this patch: > > net-change-type-of-netns_ipvs-sysctl_sync_qlen_max.patch and > > net-fix-functions-and-variables-related-to-netns_ipvs-sysctl_sync_qlen_max.patch > > are joined at the hip and should be redone as a single patch with a > > suitable changelog, please. And with a cc:net...@vger.kernel.org. > > Agreed, Zhang Yanfei and Simon? I'm just not sure, > may be this combined patch should hit only the > ipvs->nf->net trees? Or may be net-next, if we don't have > time for 3.8. ipvs->nf->net seems to be the most logical approach unless Andrew wishes to take it. I assume that at this point its too late for v3.8 and I'm not entirely clear that the changes is needed there anyway. -- 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: manual merge of the usb tree with the driver-core tree
On Mon, Feb 18, 2013 at 03:32:42PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the usb tree got a conflict in
> drivers/usb/host/ehci-vt8500.c between commit 148e11349b0c ("usb: Convert
> to devm_ioremap_resource()") from the driver-core tree and commit
> d57ada0c37ec ("USB: EHCI: make ehci-vt8500 a separate driver") from the
> usb tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good to me, thanks.
greg k-h
--
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/
i915 black screen introduced by ACPI changes
My Lenovo Y580 laptop with FC18 start to get black screen after the kernel upgrade to 3.7.xxx The black screen happens about the time kernel switch to using VT console. At the point of black screen, no response of cap locks key led no network connection. The machine seems dead. The CPU is i7 and it has two video card. The Intel build-in video card and Gtx 660M Nvidia card. This is very annoying. I did some poking around it: - It was fine on the FC18 3.6.xxx kernel before the upgrade. - The black screen exists with FC18 3.7.xxx kernel - The black screen also exists in latest tip of linux-2.6. - Switch to multi-user mode booting does not get rid of the black screen. - Get rid of the "rhrb quit" does not help either. - When the black screen happen, cap lock LED does not response to cap locks. - No networking when black screen happen. The only thing to do is reboot the system. - Adding "i915.modeset=0" will allow the kernel to boot into GUI login. However, logout of X will cause the machine to hang similar to the black screen. - Suspend and resume will get stuck at the black screen with"i915.modeset=0". - Kernel console and X is using the Intel driver for display. There are other user experience the same problem as well. http://forums.fedoraforum.org/showthread.php?t=287853 The black screen is introduced between v3.6 and v3.7. I did the git bisect. It points to this ACPI change which is a little bit surprising. I was expecting some change relate to i915 driver. I double check commit before this does not have black screen. Anyway, any suggestion to nail down this problem? I am happy to reproduce and verify the fix. Thanks Chris commit a57f7f9175b8ccbc9df83ac13860488913115de4 Author: Bob Moore Date: Fri Aug 17 10:55:02 2012 +0800 ACPICA: Add Windows8/Server2012 string for _OSI method. This change adds a new _OSI string, "Windows 2012" for both Windows 8 and Windows Server 2012. From Microsoft document "How to Identify the Windows Version in ACPI by Using _OSI", July 13, 2012. Signed-off-by: Bob Moore Signed-off-by: Feng Tang Signed-off-by: Len Brown -- 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: manual merge of the usb tree with the driver-core tree
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in
drivers/usb/host/ehci-vt8500.c between commit 148e11349b0c ("usb: Convert
to devm_ioremap_resource()") from the driver-core tree and commit
d57ada0c37ec ("USB: EHCI: make ehci-vt8500 a separate driver") from the
usb 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 drivers/usb/host/ehci-vt8500.c
index 7ecf709,98d65bd..000
--- a/drivers/usb/host/ehci-vt8500.c
+++ b/drivers/usb/host/ehci-vt8500.c
@@@ -16,7 -16,12 +16,13 @@@
*
*/
+#include
+ #include
+ #include
+ #include
+ #include
+ #include
+ #include
#include
#include
pgpsubT0pdnvL.pgp
Description: PGP signature
Re: [RFC][PATCH] kvm: fix a race when closing irq eventfd
On 2013/2/18 12:09, Li Zefan wrote:
> On 2013/2/18 12:02, Alex Williamson wrote:
>> On Mon, 2013-02-18 at 11:13 +0800, Li Zefan wrote:
>>> While trying to fix a race when closing cgroup eventfd, I took a look
>>> at how kvm deals with this problem, and I found it doesn't.
>>>
>>> I may be wrong, as I don't know kvm code, so correct me if I'm.
>>>
>>> /*
>>> * Race-free decouple logic (ordering is critical)
>>> */
>>> static void
>>> irqfd_shutdown(struct work_struct *work)
>>>
>>> I don't think it's race-free!
>>>
>>> static int
>>> irqfd_wakeup(wait_queue_t *wait, unsigned mode, int sync, void *key)
>>> {
>>> ...
>>> * We cannot race against the irqfd going away since the
>>> * other side is required to acquire wqh->lock, which
>>> we hold
>>> */
>>> if (irqfd_is_active(irqfd))
>>> irqfd_deactivate(irqfd);
>>> }
>>>
>>> In kvm_irqfd_deassign() and kvm_irqfd_release() where irqfds are freed,
>>> wqh->lock is not acquired!
>>>
>>> So here is the race:
>>>
>>> CPU0CPU1
>>> --- -
>>> kvm_irqfd_release()
>>> spin_lock(kvm->irqfds.lock);
>>> ...
>>> irqfd_deactivate(irqfd);
>>> list_del_init(>list);
>>> spin_unlock(kvm->irqfd.lock);
>>> ...
>>> close(eventfd)
>>> irqfd_wakeup();
>>
>> irqfd_wakeup is assumed to be called with wqh->lock held
>>
>
> I'm aware of this.
>
> As I said, kvm_irqfd_deassign() and kvm_irqfd_release() are not acquiring
> wqh->lock.
>
>>> irqfd_shutdown();
>>
>> eventfd_ctx_remove_wait_queue has to acquire wqh->lock to complete or
>> else irqfd_shutdown never makes it to the kfree. So in your scenario
>> this cpu0 spins here until cpu1 completes.
>>
Oh you're right, this is not obvious. Thanks for the explanation.
Now I'll go to see how to fix cgroup.
>>> remove_waitqueue(irqfd->wait);
>>> kfree(irqfd);
>>> spin_lock(kvm->irqfd.lock);
>>> if (!list_empty(>list))
>>
>> We don't take this branch because we already did list_del_init above,
>> which makes irqfd->list empty.
>>
>
> It doesn't matter if the list is empty or not.
>
> The point is, irqfd has been kfreed, so the if statement is simply not safe!
>
>>> irqfd_deactivate(irqfd);
>>> list_del_init(>list);
>>> spin_unlock(kvm->irqfd.lock);
>>>
>>> Look, we're accessing irqfd though it has already been freed!
>>
>> Unless the irqfd_wakeup path isn't acquiring wqh->lock, it looks
>> race-free to me. 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/
Re: [RFC][PATCH] kvm: fix a race when closing irq eventfd
On Mon, 2013-02-18 at 12:09 +0800, Li Zefan wrote:
> On 2013/2/18 12:02, Alex Williamson wrote:
> > On Mon, 2013-02-18 at 11:13 +0800, Li Zefan wrote:
> >> While trying to fix a race when closing cgroup eventfd, I took a look
> >> at how kvm deals with this problem, and I found it doesn't.
> >>
> >> I may be wrong, as I don't know kvm code, so correct me if I'm.
> >>
> >>/*
> >> * Race-free decouple logic (ordering is critical)
> >> */
> >>static void
> >>irqfd_shutdown(struct work_struct *work)
> >>
> >> I don't think it's race-free!
> >>
> >>static int
> >>irqfd_wakeup(wait_queue_t *wait, unsigned mode, int sync, void *key)
> >>{
> >>...
> >> * We cannot race against the irqfd going away since the
> >> * other side is required to acquire wqh->lock, which
> >> we hold
> >> */
> >>if (irqfd_is_active(irqfd))
> >>irqfd_deactivate(irqfd);
> >>}
> >>
> >> In kvm_irqfd_deassign() and kvm_irqfd_release() where irqfds are freed,
> >> wqh->lock is not acquired!
> >>
> >> So here is the race:
> >>
> >> CPU0CPU1
> >> --- -
> >> kvm_irqfd_release()
> >> spin_lock(kvm->irqfds.lock);
> >> ...
> >> irqfd_deactivate(irqfd);
> >> list_del_init(>list);
> >> spin_unlock(kvm->irqfd.lock);
> >> ...
> >>close(eventfd)
> >> irqfd_wakeup();
> >
> > irqfd_wakeup is assumed to be called with wqh->lock held
> >
>
> I'm aware of this.
>
> As I said, kvm_irqfd_deassign() and kvm_irqfd_release() are not acquiring
> wqh->lock.
They do when they call eventfd_ctx_remove_wait_queue. The irqfd is
enabled until that point and the list_del_init prevents multiple paths
from calling irqfd_deactivate.
> >> irqfd_shutdown();
> >
> > eventfd_ctx_remove_wait_queue has to acquire wqh->lock to complete or
> > else irqfd_shutdown never makes it to the kfree. So in your scenario
> > this cpu0 spins here until cpu1 completes.
> >
> >> remove_waitqueue(irqfd->wait);
> >> kfree(irqfd);
> >>spin_lock(kvm->irqfd.lock);
> >> if (!list_empty(>list))
> >
> > We don't take this branch because we already did list_del_init above,
> > which makes irqfd->list empty.
> >
>
> It doesn't matter if the list is empty or not.
Note that this is not kvm->irqfds.items, we're testing whether the
individual irqfd is detached from the list.
> The point is, irqfd has been kfreed, so the if statement is simply not safe!
It cannot be kfreed. As noted above the cpu0 path stops trying to
acquire wqh->lock which already owned by cpu1. The call to
eventfd_ctx_remove_wait_queue atomically removes the wait queue once the
wqh->lock is acquired, so after that point we're ok to kfree it.
Thanks,
Alex
> >>irqfd_deactivate(irqfd);
> >> list_del_init(>list);
> >>spin_unlock(kvm->irqfd.lock);
> >>
> >> Look, we're accessing irqfd though it has already been freed!
> >
> > Unless the irqfd_wakeup path isn't acquiring wqh->lock, it looks
> > race-free to me. Thanks,
> >
> > Alex
> >
> > .
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: [RFC][PATCH] kvm: fix a race when closing irq eventfd
On 2013/2/18 12:02, Alex Williamson wrote:
> On Mon, 2013-02-18 at 11:13 +0800, Li Zefan wrote:
>> While trying to fix a race when closing cgroup eventfd, I took a look
>> at how kvm deals with this problem, and I found it doesn't.
>>
>> I may be wrong, as I don't know kvm code, so correct me if I'm.
>>
>> /*
>> * Race-free decouple logic (ordering is critical)
>> */
>> static void
>> irqfd_shutdown(struct work_struct *work)
>>
>> I don't think it's race-free!
>>
>> static int
>> irqfd_wakeup(wait_queue_t *wait, unsigned mode, int sync, void *key)
>> {
>> ...
>> * We cannot race against the irqfd going away since the
>> * other side is required to acquire wqh->lock, which
>> we hold
>> */
>> if (irqfd_is_active(irqfd))
>> irqfd_deactivate(irqfd);
>> }
>>
>> In kvm_irqfd_deassign() and kvm_irqfd_release() where irqfds are freed,
>> wqh->lock is not acquired!
>>
>> So here is the race:
>>
>> CPU0CPU1
>> --- -
>> kvm_irqfd_release()
>> spin_lock(kvm->irqfds.lock);
>> ...
>> irqfd_deactivate(irqfd);
>> list_del_init(>list);
>> spin_unlock(kvm->irqfd.lock);
>> ...
>> close(eventfd)
>>irqfd_wakeup();
>
> irqfd_wakeup is assumed to be called with wqh->lock held
>
I'm aware of this.
As I said, kvm_irqfd_deassign() and kvm_irqfd_release() are not acquiring
wqh->lock.
>> irqfd_shutdown();
>
> eventfd_ctx_remove_wait_queue has to acquire wqh->lock to complete or
> else irqfd_shutdown never makes it to the kfree. So in your scenario
> this cpu0 spins here until cpu1 completes.
>
>> remove_waitqueue(irqfd->wait);
>> kfree(irqfd);
>> spin_lock(kvm->irqfd.lock);
>>if (!list_empty(>list))
>
> We don't take this branch because we already did list_del_init above,
> which makes irqfd->list empty.
>
It doesn't matter if the list is empty or not.
The point is, irqfd has been kfreed, so the if statement is simply not safe!
>> irqfd_deactivate(irqfd);
>>list_del_init(>list);
>> spin_unlock(kvm->irqfd.lock);
>>
>> Look, we're accessing irqfd though it has already been freed!
>
> Unless the irqfd_wakeup path isn't acquiring wqh->lock, it looks
> race-free to me. 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/
Re: [RFC][PATCH] kvm: fix a race when closing irq eventfd
On Mon, 2013-02-18 at 11:13 +0800, Li Zefan wrote:
> While trying to fix a race when closing cgroup eventfd, I took a look
> at how kvm deals with this problem, and I found it doesn't.
>
> I may be wrong, as I don't know kvm code, so correct me if I'm.
>
> /*
>* Race-free decouple logic (ordering is critical)
>*/
> static void
> irqfd_shutdown(struct work_struct *work)
>
> I don't think it's race-free!
>
> static int
> irqfd_wakeup(wait_queue_t *wait, unsigned mode, int sync, void *key)
> {
> ...
>* We cannot race against the irqfd going away since the
>* other side is required to acquire wqh->lock, which
> we hold
>*/
> if (irqfd_is_active(irqfd))
> irqfd_deactivate(irqfd);
> }
>
> In kvm_irqfd_deassign() and kvm_irqfd_release() where irqfds are freed,
> wqh->lock is not acquired!
>
> So here is the race:
>
> CPU0CPU1
> --- -
> kvm_irqfd_release()
> spin_lock(kvm->irqfds.lock);
> ...
> irqfd_deactivate(irqfd);
> list_del_init(>list);
> spin_unlock(kvm->irqfd.lock);
> ...
> close(eventfd)
> irqfd_wakeup();
irqfd_wakeup is assumed to be called with wqh->lock held
> irqfd_shutdown();
eventfd_ctx_remove_wait_queue has to acquire wqh->lock to complete or
else irqfd_shutdown never makes it to the kfree. So in your scenario
this cpu0 spins here until cpu1 completes.
> remove_waitqueue(irqfd->wait);
> kfree(irqfd);
> spin_lock(kvm->irqfd.lock);
> if (!list_empty(>list))
We don't take this branch because we already did list_del_init above,
which makes irqfd->list empty.
> irqfd_deactivate(irqfd);
> list_del_init(>list);
> spin_unlock(kvm->irqfd.lock);
>
> Look, we're accessing irqfd though it has already been freed!
Unless the irqfd_wakeup path isn't acquiring wqh->lock, it looks
race-free to me. 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/
Re: [PATCH v2] ata: Fix DVD not dectected at some Haswell platforms
> > As to my understanding Sergei did not suggest citing the whole commit message. > I also find the numerous references to Sandy Bridge confusing as this is a fix > for Lynx Point chipset. > > How about rephrasing the commit message in a way similar to the following one? > --8<- > We've hit a problem with DVD not recognized on Haswell Desktop platform which > includes Lynx Point 2-port SATA controller. This quirk patch disables 32bit > PIO on the controller in IDE mode. > -->8- Thanks Libor! I have updated the comments and sent out a v3 patch out to LKML. > > + .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SIDPR | > > PIIX_FLAG_PIO16, > > The line might be worth splitting as it's over 80 characters. > > Otherwise the patch looks OK to me. > Also change it in v3 patch. Thanks -Youquan -- 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 v3] ata: Fix DVD not dectected at some Haswell platforms
There is a quirk patch 5e5a4f5d5a08c9c504fe956391ac3dae2c66556d
"ata_piix: make DVD Drive recognisable on systems with Intel Sandybridge
chipsets(v2)" fixing the 4 ports IDE controller 32bit PIO mode.
We've hit a problem with DVD not recognized on Haswell Desktop platform which
includes Lynx Point 2-port SATA controller.
This quirk patch disables 32bit PIO on this controller in IDE mode.
v2: Change spelling error in statememnt pointed by Sergei Shtylyov.
v3: Change comment statememnt and spliting line over 80 characters pointed by
Libor Pechacek and also rebase the patch against 3.8-rc7 kernel.
Tested-by: Lee, Chun-Yi
Signed-off-by: Youquan Song
Cc: sta...@vger.kernel.org
---
drivers/ata/ata_piix.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 174eca6..4aab550 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -150,6 +150,7 @@ enum piix_controller_ids {
tolapai_sata,
piix_pata_vmw, /* PIIX4 for VMware, spurious DMA_ERR */
ich8_sata_snb,
+ ich8_2port_sata_snb,
};
struct piix_map_db {
@@ -304,7 +305,7 @@ static const struct pci_device_id piix_pci_tbl[] = {
/* SATA Controller IDE (Lynx Point) */
{ 0x8086, 0x8c01, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata_snb },
/* SATA Controller IDE (Lynx Point) */
- { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
+ { 0x8086, 0x8c08, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata_snb },
/* SATA Controller IDE (Lynx Point) */
{ 0x8086, 0x8c09, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_2port_sata },
/* SATA Controller IDE (Lynx Point-LP) */
@@ -422,6 +423,7 @@ static const struct piix_map_db *piix_map_db_table[] = {
[ich8m_apple_sata] = _apple_map_db,
[tolapai_sata] = _map_db,
[ich8_sata_snb] = _map_db,
+ [ich8_2port_sata_snb] = _2port_map_db,
};
static struct pci_bits piix_enable_bits[] = {
@@ -1225,6 +1227,16 @@ static struct ata_port_info piix_port_info[] = {
.udma_mask = ATA_UDMA6,
.port_ops = _sata_ops,
},
+
+ [ich8_2port_sata_snb] =
+ {
+ .flags = PIIX_SATA_FLAGS | PIIX_FLAG_SIDPR
+ | PIIX_FLAG_PIO16,
+ .pio_mask = ATA_PIO4,
+ .mwdma_mask = ATA_MWDMA2,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = _sata_ops,
+ },
};
#define AHCI_PCI_BAR 5
--
1.7.7.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: [RFC] sched: The removal of idle_balance()
On Sun, 2013-02-17 at 16:54 -0500, Steven Rostedt wrote: > On Sun, 2013-02-17 at 08:14 +0100, Mike Galbraith wrote: > > > (And puts a dent in x264 ultrafast) > What about my last patch? The one that avoids idle_balance() if the > previous task was in a task_uninterruptible state. That one gave the > same performance increase that removing idle_balance() did on my box. I didn't try it, figuring it was pretty much the same as turning it off, but just did. Patch (-typo) has no effect on either x264 or hackbench (surely will for -rt, but rt tasks here aren't sent to burn in rt hell). -Mike -- 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] watchdog: davinci_wdt: update to devm_* API
Hi,
On Fri, Feb 08, 2013 at 13:09:30, Kumar, Anil wrote:
> Update the code to use devm_* API so that driver
> core will manage resources.
>
> Signed-off-by: Kumar, Anil
> ---
> This patch applies on top of v3.8-rc6.
>
> Tested on da850 EVM.
>
> Changes for V2:
> - Use return -EADDRNOTAVAIL in case of devm_request_and_ioremap() fail.
> - Use devm_clk_get() instead of clk_get().
> - Revert back the change for *dev.
> - Removes static type for "wdt_mem" structure as it is used only
>inside the function now.
>
Gentle Ping. As there are no review comments on this patch,
Could you please pull this patch ?
> :100644 100644 e8e8724... 7df1fdc... Mdrivers/watchdog/davinci_wdt.c
> drivers/watchdog/davinci_wdt.c | 29 ++---
> 1 files changed, 6 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
> index e8e8724..7df1fdc 100644
> --- a/drivers/watchdog/davinci_wdt.c
> +++ b/drivers/watchdog/davinci_wdt.c
> @@ -69,7 +69,6 @@ static unsigned long wdt_status;
> #define WDT_REGION_INITED 2
> #define WDT_DEVICE_INITED 3
>
> -static struct resource *wdt_mem;
> static void __iomem *wdt_base;
> struct clk *wdt_clk;
>
> @@ -201,10 +200,11 @@ static struct miscdevice davinci_wdt_miscdev = {
>
> static int davinci_wdt_probe(struct platform_device *pdev)
> {
> - int ret = 0, size;
> + int ret = 0;
> struct device *dev = >dev;
> + struct resource *wdt_mem;
>
> - wdt_clk = clk_get(dev, NULL);
> + wdt_clk = devm_clk_get(dev, NULL);
> if (WARN_ON(IS_ERR(wdt_clk)))
> return PTR_ERR(wdt_clk);
>
> @@ -221,43 +221,26 @@ static int davinci_wdt_probe(struct platform_device
> *pdev)
> return -ENOENT;
> }
>
> - size = resource_size(wdt_mem);
> - if (!request_mem_region(wdt_mem->start, size, pdev->name)) {
> - dev_err(dev, "failed to get memory region\n");
> - return -ENOENT;
> - }
> -
> - wdt_base = ioremap(wdt_mem->start, size);
> + wdt_base = devm_request_and_ioremap(dev, wdt_mem);
> if (!wdt_base) {
> - dev_err(dev, "failed to map memory region\n");
> - release_mem_region(wdt_mem->start, size);
> - wdt_mem = NULL;
> - return -ENOMEM;
> + dev_err(dev, "ioremap failed\n");
> + return -EADDRNOTAVAIL;
> }
>
> ret = misc_register(_wdt_miscdev);
> if (ret < 0) {
> dev_err(dev, "cannot register misc device\n");
> - release_mem_region(wdt_mem->start, size);
> - wdt_mem = NULL;
> } else {
> set_bit(WDT_DEVICE_INITED, _status);
> }
>
> - iounmap(wdt_base);
> return ret;
> }
>
> static int davinci_wdt_remove(struct platform_device *pdev)
> {
> misc_deregister(_wdt_miscdev);
> - if (wdt_mem) {
> - release_mem_region(wdt_mem->start, resource_size(wdt_mem));
> - wdt_mem = NULL;
> - }
> -
> clk_disable_unprepare(wdt_clk);
> - clk_put(wdt_clk);
>
> return 0;
> }
> --
> 1.7.4.1
>
>
Thanks,
Anil
--
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: manual merge of the tip tree with the kbuild tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in
kernel/timeconst.pl between commit 70730bca1331 ("kernel: Replace
timeconst.pl with a bc script") from the kbuild tree and commit
63a3f603413f ("timeconst.pl: Eliminate Perl warning") from the tip tree.
I just droppped the tip tree version (I deleted the file) and can carry
the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpJVTRjLYwxv.pgp
Description: PGP signature
Re: [PATCH firmware] rtl_nic: update firmware for RTL8168G
On Wed, 2013-02-06 at 23:18 +0800, Hayes Wang wrote: > File: rtl_nic/rtl8168g-2.fw > Version: 0.0.1 > > This firmware supports new fw setting mothod for linux kernel. > > Add MAC OCP settings for: > -phy reset > -PXE in ALDPS > -pwron sequence > -OBFF > > Signed-off-by: Hayes Wang > --- > WHENCE| 3 +++ > rtl_nic/rtl8168g-2.fw | Bin 0 -> 4896 bytes > 2 files changed, 3 insertions(+) > create mode 100644 rtl_nic/rtl8168g-2.fw [...] Applied, thanks. Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
[RFT][PATCH] regulator: ab8500: Remove get_voltage_sel for fixed voltage
Current code sets get_voltage_sel to ab8500_regulator_get_voltage_sel,
however both ab8500_regulator_mode_ops and ab8500_regulator_ops do not
have voltage_bank, voltage_reg and voltage_mask settings.
So it looks wrong to use ab8500_regulator_get_voltage_sel as
get_voltage_sel callback in these cases.
A simple fix is just not implement get_voltage_sel, regulator core will
report microvolts in sysfs even with only list_voltage().
Signed-off-by: Axel Lin
---
Just found this needs to be fixed after I sent previous ab8500 patches,
this patch is on top of previous ab8500 fixes.
Axel
drivers/regulator/ab8500.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 24d490e..67b4412 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -362,7 +362,6 @@ static struct regulator_ops ab8500_regulator_mode_ops = {
.get_optimum_mode = ab8500_regulator_get_optimum_mode,
.set_mode = ab8500_regulator_set_mode,
.get_mode = ab8500_regulator_get_mode,
- .get_voltage_sel= ab8500_regulator_get_voltage_sel,
.list_voltage = regulator_list_voltage_linear,
.set_voltage_time_sel = ab8500_regulator_set_voltage_time_sel,
};
@@ -371,7 +370,6 @@ static struct regulator_ops ab8500_regulator_ops = {
.enable = ab8500_regulator_enable,
.disable= ab8500_regulator_disable,
.is_enabled = ab8500_regulator_is_enabled,
- .get_voltage_sel= ab8500_regulator_get_voltage_sel,
.list_voltage = regulator_list_voltage_linear,
};
--
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: usb_wwan_write() called while device still being resumed
On 02/15/2013 08:05 PM, Bjørn Mork wrote:
Maybe something like the completely untested:
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 3148b10..38e19ba 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -512,6 +512,9 @@ static int rpm_resume(struct device *dev, int rpmflags)
else if (dev->power.disable_depth == 1 && dev->power.is_suspended
&& dev->power.runtime_status == RPM_ACTIVE)
retval = 1;
+ else if (rpmflags & RPM_ASYNC && dev->power.request_pending &&
+dev->power.request == RPM_REQ_RESUME)
+ retval = -EINPROGRESS;
else if (dev->power.disable_depth > 0)
retval = -EACCES;
if (retval)
Second thought: not sure this will work since power.request_pending and
power.request are set to these values later in the same rpm_resume()
function. However, the three lines before yours caught my attention.
They are not in my 3.1 source tree and the conditions are very close
from the ones I am seeing when the issue happens: disable_depth == 1,
is_suspended == 1. Only runtime_status is not equal to RPM_ACTIVE.
Nonetheless, I have looked at the patch that introduced these
(http://pastebin.com/PmHUjiAE ) and it details a problem that is very
similar to mine. It also mentions a workaround to be implemented in the
driver by saving the suspend status into a variable that is checked when
pm_runtime_get() return -EACCES. This variable already exists in
usb_wwan, actually it is the very variable that is checked a bit later
in that other chunk of code you mentioned:
spin_lock_irqsave(>susp_lock, flags);
if (intfdata->suspended) {
usb_anchor_urb(this_urb, >delayed);
spin_unlock_irqrestore(>susp_lock, flags);
} else {
So it looks like this code is here for exactly that purpose. However in
my current condition I do not see how this block could be run since
runtime PM is disabled when intfdata->suspended is set to true.
I will try implementing the workaround suggested (checking if
intfdata->suspended is set when -EACCES is returned and go on if it is
the case) and see if it works (and I bet it will). In the upstream
kernel the issue seems to have been addressed already, so this might
just be a source-out-of-date issue.
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/
Re: [PATCH v9 4/4] sd: change to auto suspend mode
On Wed, Feb 06, 2013 at 10:51:19AM -0500, Alan Stern wrote:
> On Wed, 6 Feb 2013, Aaron Lu wrote:
>
> > > The "if (err == -EAGAIN)" test and the call to pm_schedule_suspend seem
> > > to have been dropped since v8 of this series. It looks like they ought
> > > to be moved into sdev_runtime_suspend.
> >
> > I thought they were no longer needed...
>
> You did not mention this in the patch description.
Sorry about that.
>
> > For sd, we have request based rutime PM and the PM core will always try
> > to autosuspend the device with the timer; and for sr, the poll will
> > trigger suspend constantly.
>
> What if the poll has been disabled?
>
> > And for both, we don't return -EAGAIN anyway.
> > So I suppose that code is not necessary?
>
> You could replace it with WARN_ON(err == -EAGAIN). That way if some
> SCSI driver does return -EAGAIN in the future, people will know
> something is wrong.
Placing a WARN_ON there seems to suggest drivers should not return
-EAGAIN, so I think I'll just add back those dropped code to
sdev_runtime_suspend as you have suggested like this:
static int sdev_runtime_suspend(struct device *dev)
{
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
int (*cb)(struct device *) = pm ? pm->runtime_suspend : NULL;
struct scsi_device *sdev = to_scsi_device(dev);
int ret;
if (sdev->request_queue->dev)
return sdev_blk_runtime_suspend(sdev, cb);
ret = scsi_dev_type_suspend(dev, cb);
if (ret == -EAGAIN)
pm_schedule_suspend(dev, jiffies_to_msecs(
round_jiffies_up_relative(HZ/10)));
return ret;
}
Does this look OK?
>
> > BTW, I'll be on vocation till 02/17, and I don't have access to the
> > internet in my hometown, but please feel free to drop any comments and
> > I'll check them when I get back.
>
> I'm going on vacation next week too. Enjoy your trip.
Thanks, the trip was great.
-Aaron
--
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] Bluetooth: btmrvl_sdio: look for sd8688 firmware in alternate place
On Sun, 2013-01-27 at 12:21 +0100, Lubomir Rintel wrote: > On Mon, 2013-01-21 at 01:12 +, Ben Hutchings wrote: > > On Fri, 2013-01-18 at 08:33 +0100, Lubomir Rintel wrote: > > > On Tue, 2013-01-08 at 22:35 -0800, Marcel Holtmann wrote: > > > > Hi Lubomir, > > > > > > > > > > > > linux-firmware ships the sd8688* firmware images that are > > > > > > > > shared with > > > > > > > > libertas_sdio WiFi driver under libertas/. libertas_sdio looks > > > > > > > > in both places > > > > > > > > and so should we. > > > > > > > > > > > > > > > > Signed-off-by: Lubomir Rintel > > > > > > > > --- > > > > > > > > drivers/bluetooth/btmrvl_sdio.c | 24 ++-- > > > > > > > > drivers/bluetooth/btmrvl_sdio.h |6 -- > > > > > > > > 2 files changed, 26 insertions(+), 4 deletions(-) > > > > > > > > > > > > > > NAK from me on this one. I do not want the driver to check two > > > > > > > locations. That is what userspace can work around. > > > > > > > > > > > > > > If we want to unify the location between the WiFi driver and the > > > > > > > Bluetooth driver, I am fine with that, but seriously, just pick > > > > > > > one over > > > > > > > the other. I do not care which one. > > > > > > > > > > > > The unified location is mrvl/ directory. > > > > > > > > > > > > We can probably move SD8688 firmware & helper binaries to mrvl/ and > > > > > > have both drivers grab the images there? > > > > > > > > > > That would break existing setups, wouldn't it? > > > > > > > > > > I was under impression (commit 3d32a58b) that we care about > > > > > compatibility here. Do we? > > > > > > > > that is what symlinks are for. > > > > > > David, Ben: please pull the following branch then: > > > git pull git://github.com/lkundrak/linux-firmware.git sd8688-move > > > > > > Thank you! > > > > The symlinks are broken, and you didn't update WHENCE. > > Oops, sorry for that. Fixed now, please pull: > git pull git://github.com/lkundrak/linux-firmware.git sd8688-move > > Thank you! Pulled and will be pushed out shortly. Sorry for the delay. Ben. -- Ben Hutchings Sturgeon's Law: Ninety percent of everything is crap. signature.asc Description: This is a digitally signed message part
[RFC][PATCH] kvm: fix a race when closing irq eventfd
While trying to fix a race when closing cgroup eventfd, I took a look
at how kvm deals with this problem, and I found it doesn't.
I may be wrong, as I don't know kvm code, so correct me if I'm.
/*
* Race-free decouple logic (ordering is critical)
*/
static void
irqfd_shutdown(struct work_struct *work)
I don't think it's race-free!
static int
irqfd_wakeup(wait_queue_t *wait, unsigned mode, int sync, void *key)
{
...
* We cannot race against the irqfd going away since the
* other side is required to acquire wqh->lock, which
we hold
*/
if (irqfd_is_active(irqfd))
irqfd_deactivate(irqfd);
}
In kvm_irqfd_deassign() and kvm_irqfd_release() where irqfds are freed,
wqh->lock is not acquired!
So here is the race:
CPU0CPU1
--- -
kvm_irqfd_release()
spin_lock(kvm->irqfds.lock);
...
irqfd_deactivate(irqfd);
list_del_init(>list);
spin_unlock(kvm->irqfd.lock);
...
close(eventfd)
irqfd_wakeup();
irqfd_shutdown();
remove_waitqueue(irqfd->wait);
kfree(irqfd);
spin_lock(kvm->irqfd.lock);
if (!list_empty(>list))
irqfd_deactivate(irqfd);
list_del_init(>list);
spin_unlock(kvm->irqfd.lock);
Look, we're accessing irqfd though it has already been freed!
Here's a fix I have. Please enlighten me with a better fix.
Signed-off-by: Li Zefan
---
fs/eventfd.c| 34 ++
include/linux/eventfd.h | 17 +
virt/kvm/eventfd.c | 45 +++--
3 files changed, 66 insertions(+), 30 deletions(-)
diff --git a/fs/eventfd.c b/fs/eventfd.c
index 35470d9..cda8a4c 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -22,21 +22,6 @@
#include
#include
-struct eventfd_ctx {
- struct kref kref;
- wait_queue_head_t wqh;
- /*
-* Every time that a write(2) is performed on an eventfd, the
-* value of the __u64 being written is added to "count" and a
-* wakeup is performed on "wqh". A read(2) will return the "count"
-* value to userspace, and will reset "count" to zero. The kernel
-* side eventfd_signal() also, adds to the "count" counter and
-* issue a wakeup.
-*/
- __u64 count;
- unsigned int flags;
-};
-
/**
* eventfd_signal - Adds @n to the eventfd counter.
* @ctx: [in] Pointer to the eventfd context.
@@ -153,20 +138,29 @@ static void eventfd_ctx_do_read(struct eventfd_ctx *ctx,
__u64 *cnt)
* This is used to atomically remove a wait queue entry from the eventfd wait
* queue head, and read/reset the counter value.
*/
-int eventfd_ctx_remove_wait_queue(struct eventfd_ctx *ctx, wait_queue_t *wait,
+int eventfd_ctx_remove_wait_queue_locked(struct eventfd_ctx *ctx, wait_queue_t
*wait,
__u64 *cnt)
{
- unsigned long flags;
-
- spin_lock_irqsave(>wqh.lock, flags);
eventfd_ctx_do_read(ctx, cnt);
__remove_wait_queue(>wqh, wait);
if (*cnt != 0 && waitqueue_active(>wqh))
wake_up_locked_poll(>wqh, POLLOUT);
- spin_unlock_irqrestore(>wqh.lock, flags);
return *cnt != 0 ? 0 : -EAGAIN;
}
+EXPORT_SYMBOL_GPL(eventfd_ctx_remove_wait_queue_locked);
+
+int eventfd_ctx_remove_wait_queue(struct eventfd_ctx *ctx, wait_queue_t *wait,
+ __u64 *cnt)
+{
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(>wqh.lock, flags);
+ ret = eventfd_ctx_remove_wait_queue_locked(ctx, wait, cnt);
+ spin_unlock_irqrestore(>wqh.lock, flags);
+ return ret;
+}
EXPORT_SYMBOL_GPL(eventfd_ctx_remove_wait_queue);
/**
diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h
index 3c3ef19..61085ac 100644
--- a/include/linux/eventfd.h
+++ b/include/linux/eventfd.h
@@ -26,6 +26,21 @@
#define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
#define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE)
+struct eventfd_ctx {
+ struct kref kref;
+ wait_queue_head_t wqh;
+ /*
+* Every time that a write(2) is performed on an eventfd, the
+* value of the __u64 being written is added to "count" and a
+* wakeup is performed on "wqh". A read(2) will return the "count"
+* value to userspace, and will reset "count" to zero. The kernel
+* side eventfd_signal() also, adds to the "count" counter and
+* issue a
Re: [v3.8 Regression] watchdog: sp5100_tco: Add SB8x0 chipset support
On 02/17/2013 04:44 AM, Tanaka Takahisa wrote: Hi Joseph, 2013/2/15 Joseph Salisbury : On 02/15/2013 02:32 AM, Wim Van Sebroeck wrote: Hi Joseph, A bug was opened against the Ubuntu kernel[0]. It was found that reverting the following commit resolved this bug: commit 740fbddf5c3f9ad8b23c5d917ba1cc7e376a5104 Author: Takahisa Tanaka Date: Sun Dec 2 14:33:18 2012 +0900 watchdog: sp5100_tco: Add SB8x0 chipset support The regression was introduced as of v3.8-rc1. I see that you are the author of this patch, so I wanted to run this by you. I was thinking of requesting a revert for v3.8, but I wanted to get your feedback first. Please check out the attached patches first (They are allready in linux-next). Thanks for the feedback, Wim. I'll let you know if the patches resolve this bug. Other references: Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176 Kind regards, Wim. Thank you for your information, and sorry for the late reply. I think that I will get rid of code that re-programming the chipset registers, if my patch set doesn't resolve the problem. I'm waiting for your reply at the moment. Regards, Takahisa Hi Takahisa, The bug report tested a kernel with the patches. However, he reports the kernel panic still occurs[0]. Thanks, Joe [0] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1116835 -- 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/
[RFT][PATCH 2/2] regulator: ab8500: Use regulator_list_voltage_linear for fixed voltage
Both ab8500_regulator_mode_ops and ab8500_regulator_ops do not have volt_table
setting, thus we can not use regulator_list_voltage_table for them.
However, they have min_uV setting with n_voltages = 1, so use
regulator_list_voltage_linear instead.
Signed-off-by: Axel Lin
---
drivers/regulator/ab8500.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index ffabff7..24d490e 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -363,7 +363,7 @@ static struct regulator_ops ab8500_regulator_mode_ops = {
.set_mode = ab8500_regulator_set_mode,
.get_mode = ab8500_regulator_get_mode,
.get_voltage_sel= ab8500_regulator_get_voltage_sel,
- .list_voltage = regulator_list_voltage_table,
+ .list_voltage = regulator_list_voltage_linear,
.set_voltage_time_sel = ab8500_regulator_set_voltage_time_sel,
};
@@ -372,7 +372,7 @@ static struct regulator_ops ab8500_regulator_ops = {
.disable= ab8500_regulator_disable,
.is_enabled = ab8500_regulator_is_enabled,
.get_voltage_sel= ab8500_regulator_get_voltage_sel,
- .list_voltage = regulator_list_voltage_table,
+ .list_voltage = regulator_list_voltage_linear,
};
static struct ab8500_regulator_info
--
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/
[RFT][PATCH 1/2] regulator: ab8500: Fix build error
This build error is introduced by commit 6a9fe8319
"regulator: ab8500: Added get_optimum_mode on regulators with idle mode".
CC drivers/regulator/ab8500.o
drivers/regulator/ab8500.c:500:23: error: 'ab8500_regulator_fixed_ops'
undeclared here (not in a function)
drivers/regulator/ab8500.c:510:3: error: unknown field 'update_val_enable'
specified in initializer
make[2]: *** [drivers/regulator/ab8500.o] Error 1
make[1]: *** [drivers/regulator] Error 2
make: *** [drivers] Error 2
Signed-off-by: Axel Lin
---
drivers/regulator/ab8500.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index d0ce436..ffabff7 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -494,10 +494,13 @@ static struct ab8500_regulator_info
.update_val_idle= 0x82,
.update_val_normal = 0x02,
},
+ /*
+* Regulators with fixed voltage and normal mode
+*/
[AB8500_LDO_USB] = {
.desc = {
.name = "LDO-USB",
- .ops= _regulator_fixed_ops,
+ .ops= _regulator_ops,
.type = REGULATOR_VOLTAGE,
.id = AB8500_LDO_USB,
.owner = THIS_MODULE,
@@ -507,12 +510,8 @@ static struct ab8500_regulator_info
.update_bank= 0x03,
.update_reg = 0x82,
.update_mask= 0x03,
- .update_val_enable = 0x01,
+ .update_val = 0x01,
},
-
- /*
-* Regulators with fixed voltage and normal mode
-*/
[AB8500_LDO_AUDIO] = {
.desc = {
.name = "LDO-AUDIO",
--
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: BUG in find_pid_ns
On 02/17/2013 07:17 PM, ebied...@xmission.com wrote: > The bad pointer value is 0xfff0. Hmm. > > If you have the failure location correct it looks like a corrupted hash > entry was found while following the hash chain. > > It looks like the memory has been set to -16 -EBUSY? Weird. > > It smells like something is stomping on the memory of a struct pid, with > the same hash value and thus in the same hash chain as the current pid. > > Can you reproduce this? I've just reproduced it again: [ 2404.518957] BUG: unable to handle kernel paging request at fff0 [ 2404.520024] IP: [] find_pid_ns+0x110/0x1f0 [ 2404.520024] PGD 5429067 PUD 542b067 PMD 0 [ 2404.520024] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 2404.520024] Dumping ftrace buffer: [ 2404.520024](ftrace buffer empty) [ 2404.520024] Modules linked in: [ 2404.520024] CPU 3 [ 2404.520024] Pid: 6890, comm: trinity Tainted: GW 3.8.0-rc7-next-20130215-sasha-00027-gb399f44-dirty #288 [ 2404.520024] RIP: 0010:[] [] find_pid_ns+0x110/0x1f0 [ 2404.520024] RSP: 0018:8800af1dfe18 EFLAGS: 00010286 [ 2404.520024] RAX: 0001 RBX: 4b72 RCX: [ 2404.520024] RDX: 0001 RSI: 85466e40 RDI: 0286 [ 2404.520024] RBP: 8800af1dfe48 R08: 0001 R09: 0001 [ 2404.520024] R10: 0001 R11: R12: 85466460 [ 2404.520024] R13: 8800bf8d3ef8 R14: fff0 R15: 8800a43d9a40 [ 2404.520024] FS: 7f8300f79700() GS:8800bbc0() knlGS: [ 2404.520024] CS: 0010 DS: ES: CR0: 80050033 [ 2404.520024] CR2: fff0 CR3: af0b7000 CR4: 000406e0 [ 2404.520024] DR0: DR1: DR2: [ 2404.520024] DR3: DR6: 0ff0 DR7: 0400 [ 2404.520024] Process trinity (pid: 6890, threadinfo 8800af1de000, task 8800b060b000) [ 2404.520024] Stack: [ 2404.520024] 85466e40 4b72 8800af1dfed8 [ 2404.520024] 0003 20c49ba5e353f7cf 8800af1dfe58 81131e5c [ 2404.520024] 8800af1dfec8 8112400f 81123f9c [ 2404.520024] Call Trace: [ 2404.520024] [] find_vpid+0x2c/0x30 [ 2404.520024] [] kill_something_info+0x9f/0x270 [ 2404.673395] [] ? kill_something_info+0x2c/0x270 [ 2404.673395] [] sys_kill+0x88/0xa0 [ 2404.673395] [] ? syscall_trace_enter+0x24/0x2e0 [ 2404.694324] [] ? trace_hardirqs_on_caller+0x128/0x160 [ 2404.694324] [] ? tracesys+0x7e/0xe6 [ 2404.694324] [] tracesys+0xe1/0xe6 [ 2404.694324] Code: 4d 8b 75 00 e8 b2 0e 00 00 85 c0 0f 84 d2 00 00 00 80 3d fa 17 d5 04 00 0f 85 c5 00 00 00 e9 93 00 00 00 0f 1f 84 00 00 00 00 00 <41> 39 1e 75 2b 4d 39 66 08 75 25 41 8b 84 24 20 08 00 00 48 c1 [ 2404.733487] RIP [] find_pid_ns+0x110/0x1f0 [ 2404.740299] RSP [ 2404.740299] CR2: fff0 [ 2404.740299] ---[ end trace 9f8bc22bbe4fe990 ]--- I'm not sure what debug info I could throw in which will be helpful. Dump the entire chain or table if 'pnr' happens to look odd? > Memory corruption is hard to trace down with just a single data point. > > Looking a little closer Sasha you have rewritten > hlist_for_each_entry_rcu, and that seems to be the most recent patch > dealing with pids, and we are failing in hlist_for_each_entry_rcu. > > I haven't looked at your patch in enough detail to know if you have > missed something or not, but a brand new patch and a brand new failure > certainly look suspicious at first glance. Agreed, I've also took a second look at it when this BUG popped up. What surprises me about it is that if the new iteration is broken, the kernel would spectacularly break in a bunch of places instead of failing in the exact same place twice. Not ignoring the possibility it's broken though. Thanks, Sasha -- 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] HID: ntrig: use input_configured() callback to set the name
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Looks good, and I can confirm it works fine.
Signed-off-by: Rafi Rubin
On 02/08/13 09:51, Benjamin Tissoires wrote:
> The use of input_configured() allows the ntrig driver to actually
> change the name of the input and its bitmask before it is added to
> the input subsystem. Thus, the logs are coherents and udev catch
> the real bitmask when the device is added.
>
> Signed-off-by: Benjamin Tissoires
> --- drivers/hid/hid-ntrig.c | 68
> - 1 file changed,
> 34 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/hid/hid-ntrig.c b/drivers/hid/hid-ntrig.c
> index 2ffc0e3..7757e82 100644 --- a/drivers/hid/hid-ntrig.c +++
> b/drivers/hid/hid-ntrig.c @@ -858,12 +858,43 @@ not_claimed_input:
> return 1; }
>
> +static void ntrig_input_configured(struct hid_device *hid, +
> struct hid_input *hidinput) + +{ +struct input_dev *input =
> hidinput->input; + + if (hidinput->report->maxfield < 1) +
> return; + + switch (hidinput->report->field[0]->application) { +
> case HID_DG_PEN: +input->name = "N-Trig Pen"; + break;
> +case
> HID_DG_TOUCHSCREEN: + /* These keys are redundant for fingers,
> clear them + * to prevent incorrect identification */ +
> __clear_bit(BTN_TOOL_PEN, input->keybit); +
> __clear_bit(BTN_TOOL_FINGER, input->keybit); +
> __clear_bit(BTN_0,
> input->keybit); + __set_bit(BTN_TOOL_DOUBLETAP, input->keybit); +
> /* + * The physical touchscreen (single touch) + *
> input has a
> value for physical, whereas + * the multitouch only has logical
> input +* fields. + */ + input->name =
> (hidinput->report->field[0]->physical) ? +
> "N-Trig
> Touchscreen" : + "N-Trig
> MultiTouch"; + break; +} +} +
> static int ntrig_probe(struct hid_device *hdev, const struct
> hid_device_id *id) { int ret; struct ntrig_data *nd; -struct
> hid_input *hidinput; -struct input_dev *input; struct hid_report
> *report;
>
> if (id->driver_data) @@ -901,38 +932,6 @@ static int
> ntrig_probe(struct hid_device *hdev, const struct hid_device_id
> *id) goto err_free; }
>
> - - list_for_each_entry(hidinput, >inputs, list) { - if
> (hidinput->report->maxfield < 1) -continue; - -
> input =
> hidinput->input; -switch
> (hidinput->report->field[0]->application) { - case HID_DG_PEN: -
> input->name = "N-Trig Pen"; - break; -case
> HID_DG_TOUCHSCREEN:
> - /* These keys are redundant for fingers, clear them -
> * to
> prevent incorrect identification */ -
> __clear_bit(BTN_TOOL_PEN,
> input->keybit); - __clear_bit(BTN_TOOL_FINGER,
> input->keybit); -
> __clear_bit(BTN_0, input->keybit); -
> __set_bit(BTN_TOOL_DOUBLETAP, input->keybit); - /* -
> * The
> physical touchscreen (single touch) - * input has a value for
> physical, whereas -* the multitouch only has logical
> input -
> * fields. -*/ - input->name = -
> (hidinput->report->field[0] - ->physical) ? -
> "N-Trig
> Touchscreen" : - "N-Trig MultiTouch"; -
> break; -} - } - /*
> This is needed for devices with more recent firmware versions */
> report =
> hdev->report_enum[HID_FEATURE_REPORT].report_id_hash[0x0a]; if
> (report) { @@ -1023,6 +1022,7 @@ static struct hid_driver
> ntrig_driver = { .remove = ntrig_remove, .input_mapping =
> ntrig_input_mapping, .input_mapped = ntrig_input_mapped, +
> .input_configured = ntrig_input_configured, .usage_table =
> ntrig_grabbed_usages, .event = ntrig_event, };
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJRIZQxAAoJEPILXytRLnK26REP+weeAIqA4kfDn+tWqFOXIbcL
u65bkvNQmlEqx/mUeO7i7+tOsgTJnKpMy3ec5zsfyZd5DKs2yc3DTvrNXZbnqumZ
NkUYe7+aob1ge4+edJKw9nWDHp2E1sCm7VDNXVcEUTQN1ntMp/BjMenhDjgWhXVw
/3meslXrD3TOvXx/FzDLzJdV1WdBPeOHTHZq/yxsI3Z5jWCFba/Xz1CHc62sd2Og
hRTe9CthK3Hq9EQJXOc8qSBgNkhQ6XtBZb7KTw7FXAyKH3htus6t3c57ZPqGUUER
i6rasUYs3QGQQDG3tEU4wnWEtkS0i+9SO9L8tkUJwTKmdn7rDd5oAwovwMghkEkb
L1+tKL8EamC1oD8CMfHa7zCOTlkfTT0eRJiyHIErWpxn+VQxx2fpR7/MS2fF9n60
ecNGCRGrQo1UvIpYHmmGfigptcp6kyDgl8H9KBjafbQI5OWrJanwPi3aIXYhZmo8
XLjqCRJfgeJKFZD3mTdgqKL0hpNldskNUUauFD5GJblAB3UQ/MZ5Nmm+hWi3Y7y2
e0zxkPzw1puBFNNA06KLUNJ1DyibBZTPua1h36bD+OtqcRXIi8cdMHVf7bZhWSUK
ePVxgYjbgybAh4gMTgRQP/ucEuc6eDHGQ6MRe16ezwk3+fvUiLPntAtTXro1e3ck
nN0+r/NQSn7PKOdCqgeF
=ltkV
-END PGP
Re: Stupid user with user-space questions, matrix LED driving with user space code only.
On Sun, Feb 17, 2013 at 02:37:24PM +, Jonathan Andrews wrote: > From a user perspective it seems a bit crap to have to change the kernel > if you have a workload that preemption is harmful to. > In the case of something like the Raspberry Pi changing the kernel if > the distribution has not done the work for me sounds like real effort. > The kernel is tied to binary obscurity from broadcom... To build I need > a working cross compiler, toolchain, kernel sources, Pi specific patches > then to get everything in the correct place on an SD card containing two > filesystems. Its possible but its not going to "just work" at my skill > level As you can not boot a kernel.org kernel on the RPI platform just yet, there's very little that the kernel.org community can do here to help you out. I suggest you go take this up with the developers whom you got this specific kernel build from, there's nothing we can do here about it. Best of luck, greg k-h -- 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] backlight: lm3630: remove ret = -EIO of lm3630_backlight_register()
2013년 02월 04일 09:14, Jingoo Han 쓴 글: There is no need to return -EIO, because backlight_device_register() already returns correct error values. Signed-off-by: Jingoo Han --- drivers/video/backlight/lm3630_bl.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/backlight/lm3630_bl.c b/drivers/video/backlight/lm3630_bl.c index a6d637b..76a62e9 100644 --- a/drivers/video/backlight/lm3630_bl.c +++ b/drivers/video/backlight/lm3630_bl.c @@ -320,7 +320,7 @@ static int lm3630_backlight_register(struct lm3630_chip_data *pchip, backlight_device_register(name, pchip->dev, pchip, _bank_a_ops, ); if (IS_ERR(pchip->bled1)) - return -EIO; + return PTR_ERR(pchip->bled1); break; case BLED_2: props.brightness = pdata->init_brt_led2; @@ -329,7 +329,7 @@ static int lm3630_backlight_register(struct lm3630_chip_data *pchip, backlight_device_register(name, pchip->dev, pchip, _bank_b_ops, ); if (IS_ERR(pchip->bled2)) - return -EIO; + return PTR_ERR(pchip->bled2); break; } return 0; Thank you. This patch looks good for us. Acked-by: Daniel Jeong -- 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/
prctl(PR_SET_MM)
Hello, The code in "kernel/sys.c" provides the "prctl(PR_SET_MM)" function, which is the only way a process can set or modify the following 11 per-process fields: start_code, end_code, start_data, end_data, start_brk, brk, start_stack, arg_start, arg_end, env_start, env_end. Being able to set those fields is important, even crucial, for any conceivable user-level checkpointing software, as well as for migrating processes between different computers. Unfortunately, this code (essentially "prctl_set_mm()") is presently enclosed in "#ifdef CONFIG_CHECKPOINT_RESTORE" which is configured as "default n" in "init/Kconfig". Many system-administrators who may like to have a checkpoint/restore or process-migration facility, but use standard pre-packaged kernels, find the requirement to configure and compile their own non-standard kernel difficult or too prohibitive. Would it be possible to have this code enabled by default? This could be done in one of 4 ways: 1) Having CONFIG_CHECKPOINT_RESTORE enabled by default; or 2) Releasing this code from the "#ifdef CONFIG_CHECK_RESTORE"; or 3) Placing this code within a different kernel-configuration option (say "CONFIG_BASIC_CHECKPOINTING") that is enabled by default; or 4) Placing this code under a dual #if, so instead of: #ifdef CONFIG_CHECKPOINT_RESTORE have: #if defined(CONFIG_CHECKPOINT_RESTORE) || defined(CONFIG_BASIC_CHECKPOINTING) Thank you, Amnon. -- 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/
