twitter: linux.kernel - 26 new messages in 8 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Dmaengine query - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/9b54299ddc3a3745?hl=en
* input: Add support of Synaptics Clickpad device - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6cf473866d3526a3?hl=en
* Add a global synchronization point for pvclock - 18 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/76b116df6177d9b9?hl=en
* boot device order troubleshooting without an initrd - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/955739f060762d9e?hl=en
* Good Day - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d3651a178bac4d78?hl=en
* hid: Add mappings for a few keys found on Logitech MX3200 - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/36068c38d2acbc02?hl=en
* CFQ read performance regression - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f106eaf14f59195d?hl=en
* Process-shared futexes on hugepages puts the kernel in an infinite loop in 2.
6.32.11; is this fixed now? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e9a305f09a39640e?hl=en

==============================================================================
TOPIC: Dmaengine query
http://groups.google.com/group/linux.kernel/t/9b54299ddc3a3745?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Apr 19 2010 3:30 am
From: rd bairva

Hi Dan,

On Thu, Apr 15, 2010 at 6:00 AM, Dan Williams <dan.j.williams@intel.com> wrote:
> On Tue, Apr 13, 2010 at 11:26 PM, rd bairva <rbairva@gmail.com> wrote:
>> Hi Dan,
>>
>> I am currently writing dmaengine compatible DMA driver for our ARM
>> based architecture, But I am facing some performance issues doing
>> that.
>>
>> 1. dmaengine says callback should run in tasklet, and next transfer
>> cannot be scheduled from the callback.
>>
>> Due to these restrictions I am getting some performance issue while
>> playing sound in our architecture.
>>
>>
>> Can callback call in DMA driver be placed out of spin_lock to submit
>> new operations from callback? (only in asynchronous case)
>>
>> is this Ok? please comment.
>
> Other dma driver authors are dropping the lock across the call to the
> callback in the mem-to-io case. The compliance points in the
> documentation are primarily targeted at the expectations of the
> async_tx api. In the mem-to-io (slave dma) model you are not using
> the async_tx api.
>
> --
> Dan
>

My DMA controller supports device to device DMA transfers and we
need it in some of our drivers. Existing DMA engine framework doesn't
have support for device to device transfers.

Do you have any plans for device to device support in DMA engine?

Can you suggest me some other suggestion for doing this?

Regards
Ramdayal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: input: Add support of Synaptics Clickpad device
http://groups.google.com/group/linux.kernel/t/6cf473866d3526a3?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Apr 19 2010 3:40 am
From: Takashi Iwai

Hi Dmitry,

At Mon, 19 Apr 2010 01:32:22 -0700,
Dmitry Torokhov wrote:
>
> Hi Takashi,
>
> On Wed, Apr 14, 2010 at 05:10:22PM +0200, Takashi Iwai wrote:
> > Add the detection of Synaptics Clickpad device.
> > The device can be detected a new query command 0x0c. The clickpad
> > flags are in cap[0]:4 and cap[1]:0 bits. But, the driver checks
> > first the product id bits in the ext capabilities to be sure, so
> > that it skips the new check on older devices.
> >
>
> Instead of looking at the product id, can we check the number of
> supported extended capabilities queries and act accordingly, like the
> patch below?

Yes, it worked. (Though, I've tested only new machines.)

> @@ -162,6 +163,16 @@ static int synaptics_capability(struct psmouse *psmouse)
> priv->ext_cap &= 0xff0fff;
> }
> }
> +
> + if (SYN_EXT_CAP_REQUESTS(priv->capabilities) >= 4) {
> + if (synaptics_send_cmd(psmouse, SYN_QUE_EXT_CAPAB_0C, cap)) {
> + printk(KERN_ERR "Synaptics claims to have extended capability 0x0c,"
> + " but I'm not able to read it.");

Here missing a newline, BTW.

thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Mon, Apr 19 2010 3:50 am
From: Takashi Iwai

At Fri, 16 Apr 2010 10:00:20 +0200,
I wrote:
>
> At Thu, 15 Apr 2010 21:12:18 +0200,
> Pavel Machek wrote:
> >
> > Hi!
> >
> > > The new Synaptics devices have an LED on the top-left corner.
> > > This is controlled via the command 0x0a with parameters 0x88 or 0x10.
> > >
> > > The detection of the LED isn't clear yet. It should have been the new
> > > capability bits that indicate the presence, but on real machines, it
> > > doesn't fit. So, for the time being, the driver checks the product id
> > > in the ext capability bits and assumes that LED exists on the known
> > > devices.
> > >
> > > The support of LED is controlled via a normal input event with EV_LED
> > > bit mask. It supports LED_MUTE bit. X driver can detect the LED
> > > support by checking these bits.
> >
> > Could we use generic LED API for this?
>
> Yeah, actually I started implementing with LED ADI at first.
>
> But, then it turned out to be that it's much easier to use the
> existing LED input bits since this LED is really tightly coupled with
> the synaptics input device. An individual LED device makes hard to
> find out the corresponding input device.
>
> If we assume there is only one synaptics and only one synaptics-LED
> device, then yes, the situation can be a bit easier, though.
>
> > It is not really 'mute' led after all...
>
> If the problem is the misuse of LED_MUTE bit, how about adding a new
> LED bit, e.g. LED_TOUCHPAD?

The revised patch with an addition of LED_TOUCHPAD is below.

thanks,

Takashi

===

From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] input: Add LED support to Synaptics device

The new Synaptics devices have an LED on the top-left corner.
This is controlled via the command 0x0a with parameters 0x88 or 0x10.

The detection of the LED isn't clear yet. It should have been the new
capability bits that indicate the presence, but on real machines, it
doesn't fit. So, for the time being, the driver checks the product id
in the ext capability bits and assumes that LED exists on the known
devices.

The support of LED is controlled via a normal input event with EV_LED
bit mask. A new LED bitmask, LED_TOUCHPAD, is added. X driver can
detect the LED support by checking these bits.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/input/mouse/synaptics.c | 64 +++++++++++++++++++++++++++++++++++++++
drivers/input/mouse/synaptics.h | 5 +++
include/linux/input.h | 1 +
3 files changed, 70 insertions(+), 0 deletions(-)

diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index c7b5285..bffa474 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -28,6 +28,7 @@
#include <linux/input.h>
#include <linux/serio.h>
#include <linux/libps2.h>
+#include <linux/workqueue.h>
#include <linux/slab.h>
#include "psmouse.h"
#include "synaptics.h"
@@ -339,6 +340,52 @@ static void synaptics_pt_create(struct psmouse *psmouse)
* Functions to interpret the absolute mode packets
****************************************************************************/

+static void synaptics_set_led(struct psmouse *psmouse, int on)
+{
+ unsigned char param[1];
+
+ if (psmouse_sliced_command(psmouse, on ? 0x88 : 0x10))
+ return;
+ param[0] = 0x0a;
+ ps2_command(&psmouse->ps2dev, param, PSMOUSE_CMD_SETRATE);
+}
+
+static void synaptics_led_work(struct work_struct *work)
+{
+ struct synaptics_data *priv = container_of(work, struct synaptics_data, led_work);
+ synaptics_set_led(priv->psmouse, priv->led_status);
+}
+
+/* input event handler: changed by x11 synaptics driver */
+static int synaptics_led_event(struct input_dev *dev, unsigned int type,
+ unsigned int code, int value)
+{
+ struct synaptics_data *priv = dev->dev.platform_data;
+
+ if (!priv)
+ return 0;
+ if (type == EV_LED && code == LED_TOUCHPAD) {
+ priv->led_status = !!value;
+ schedule_work(&priv->led_work);
+ }
+ return 0;
+}
+
+static void synaptics_query_led(struct psmouse *psmouse)
+{
+ struct synaptics_data *priv = psmouse->private;
+
+ /* FIXME: LED is supposedly detectable in cap0c[1] 0x20, but it seems
+ * not working on real machines. So we check the product id to be sure
+ */
+ if (priv->ext_cap_0c && SYN_CAP_PRODUCT_ID(priv->ext_cap) == 0xe4)
+ printk(KERN_INFO "synaptics: support LED control\n");
+ priv->has_led = 1;
+ priv->psmouse = psmouse;
+ INIT_WORK(&priv->led_work, synaptics_led_work);
+ }
+}
+
static void synaptics_parse_hw_state(unsigned char buf[], struct synaptics_data *priv, struct synaptics_hw_state *hw)
{
memset(hw, 0, sizeof(struct synaptics_hw_state));
@@ -618,10 +665,22 @@ static void set_input_params(struct input_dev *dev, struct synaptics_data *priv)
__clear_bit(BTN_RIGHT, dev->keybit);
__clear_bit(BTN_MIDDLE, dev->keybit);
}
+ if (priv->has_led) {
+ __set_bit(EV_LED, dev->evbit);
+ __set_bit(LED_TOUCHPAD, dev->ledbit);
+ dev->event = synaptics_led_event;
+ dev->dev.platform_data = priv;
+ }
}

static void synaptics_disconnect(struct psmouse *psmouse)
{
+ struct synaptics_data *priv = psmouse->private;
+
+ if (priv->has_led) {
+ cancel_work_sync(&priv->led_work);
+ synaptics_set_led(psmouse, 0);
+ }
synaptics_reset(psmouse);
kfree(psmouse->private);
psmouse->private = NULL;
@@ -653,6 +712,9 @@ static int synaptics_reconnect(struct psmouse *psmouse)
return -1;
}

+ if (priv->has_led)
+ synaptics_set_led(psmouse, priv->led_status);
+
return 0;
}

@@ -727,6 +789,8 @@ int synaptics_init(struct psmouse *psmouse)
SYN_ID_MAJOR(priv->identity), SYN_ID_MINOR(priv->identity),
priv->model_id, priv->capabilities, priv->ext_cap, priv->ext_cap_0c);

+ synaptics_query_led(psmouse);
+
set_input_params(psmouse->dev, priv);

/*
diff --git a/drivers/input/mouse/synaptics.h b/drivers/input/mouse/synaptics.h
index ae37c5d..0b989f4 100644
--- a/drivers/input/mouse/synaptics.h
+++ b/drivers/input/mouse/synaptics.h
@@ -107,6 +107,11 @@ struct synaptics_data {
unsigned char pkt_type; /* packet type - old, new, etc */
unsigned char mode; /* current mode byte */
int scroll;
+
+ unsigned char has_led;
+ unsigned char led_status;
+ struct psmouse *psmouse;
+ struct work_struct led_work;
};

void synaptics_module_init(void);
diff --git a/include/linux/input.h b/include/linux/input.h
index 7ed2251..0aea50d 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -757,6 +757,7 @@ struct input_absinfo {
#define LED_MISC 0x08
#define LED_MAIL 0x09
#define LED_CHARGING 0x0a
+#define LED_TOUCHPAD 0x0b
#define LED_MAX 0x0f
#define LED_CNT (LED_MAX+1)

--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Add a global synchronization point for pvclock
http://groups.google.com/group/linux.kernel/t/76b116df6177d9b9?hl=en
==============================================================================

== 1 of 18 ==
Date: Mon, Apr 19 2010 3:40 am
From: Peter Zijlstra

On Fri, 2010-04-16 at 13:36 -0700, Jeremy Fitzhardinge wrote:
> > + do {
> > + last = last_value;
> >
> Does this need a barrier() to prevent the compiler from re-reading
> last_value for the subsequent lines? Otherwise "(ret < last)" and
> "return last" could execute with different values for "last".
>
ACCESS_ONCE() is your friend.

== 2 of 18 ==
Date: Mon, Apr 19 2010 3:50 am
From: Avi Kivity

On 04/19/2010 01:43 PM, Peter Zijlstra wrote:
>
>>>
>>>> +
>>>> cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
>>>> {
>>>> struct pvclock_shadow_time shadow;
>>>> unsigned version;
>>>> cycle_t ret, offset;
>>>> + u64 last;
>>>>
>>>>
>>>> + do {
>>>> + last = last_value;
>>>>
>>> Otherwise, this assignment can see a partial update.
>>>
>> On a 32-bit guest, that is.
>>
> Right, do bear in mind that the x86 implementation of atomic64_read() is
> terrifyingly expensive, it is better to not do that read and simply use
> the result of the cmpxchg.
>
>

atomic64_read() _is_ cmpxchg64b. Are you thinking of some clever
implementation for smp i386?

--
error compiling committee.c: too many arguments to function

== 3 of 18 ==
Date: Mon, Apr 19 2010 3:50 am
From: Peter Zijlstra

On Mon, 2010-04-19 at 12:46 +0200, Peter Zijlstra wrote:
> On Sat, 2010-04-17 at 21:48 +0300, Avi Kivity wrote:
> > > After this patch is applied, I don't see a single warp in time during 5 days
> > > of execution, in any of the machines I saw them before.
> > >
> > >
> >
> > Please define a cpuid bit that makes this optional. When we eventually
> > enable it in the future, it will allow a wider range of guests to enjoy it.
>
> Right, so on x86 we have:
>
> X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
> independent, not that it doesn't stop in C states and similar fun stuff.
>
> X86_FEATURE_TSC_RELIABLE, which IIRC should indicate the TSC is constant
> and synced between cores.

Fun, we also have:

X86_FEATURE_NONSTOP_TSC, which states the thing doesn't stop in C
states.

== 4 of 18 ==
Date: Mon, Apr 19 2010 3:50 am
From: Peter Zijlstra

On Sat, 2010-04-17 at 21:49 +0300, Avi Kivity wrote:
> On 04/17/2010 09:48 PM, Avi Kivity wrote:
> >
> >>
> >> +static u64 last_value = 0;
> >
> > Needs to be atomic64_t.
> >
> >> +
> >> cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
> >> {
> >> struct pvclock_shadow_time shadow;
> >> unsigned version;
> >> cycle_t ret, offset;
> >> + u64 last;
> >>
> >>
> >> + do {
> >> + last = last_value;
> >
> > Otherwise, this assignment can see a partial update.
>
> On a 32-bit guest, that is.

Right, do bear in mind that the x86 implementation of atomic64_read() is
terrifyingly expensive, it is better to not do that read and simply use
the result of the cmpxchg.

== 5 of 18 ==
Date: Mon, Apr 19 2010 3:50 am
From: Peter Zijlstra

On Sat, 2010-04-17 at 21:48 +0300, Avi Kivity wrote:
> > After this patch is applied, I don't see a single warp in time during 5 days
> > of execution, in any of the machines I saw them before.
> >
> >
>
> Please define a cpuid bit that makes this optional. When we eventually
> enable it in the future, it will allow a wider range of guests to enjoy it.

Right, so on x86 we have:

X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
independent, not that it doesn't stop in C states and similar fun stuff.

X86_FEATURE_TSC_RELIABLE, which IIRC should indicate the TSC is constant
and synced between cores.

== 6 of 18 ==
Date: Mon, Apr 19 2010 3:50 am
From: Avi Kivity

On 04/19/2010 01:46 PM, Peter Zijlstra wrote:
> On Sat, 2010-04-17 at 21:48 +0300, Avi Kivity wrote:
>
>>> After this patch is applied, I don't see a single warp in time during 5 days
>>> of execution, in any of the machines I saw them before.
>>>
>>>
>>>
>> Please define a cpuid bit that makes this optional. When we eventually
>> enable it in the future, it will allow a wider range of guests to enjoy it.
>>
> Right, so on x86 we have:
>
> X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
> independent, not that it doesn't stop in C states and similar fun stuff.
>
> X86_FEATURE_TSC_RELIABLE, which IIRC should indicate the TSC is constant
> and synced between cores.
>
>

Sockets and boards too? (IOW, how reliable is TSC_RELIABLE)?

--
error compiling committee.c: too many arguments to function

== 7 of 18 ==
Date: Mon, Apr 19 2010 4:00 am
From: Avi Kivity

On 04/19/2010 01:49 PM, Peter Zijlstra wrote:
>
>> Right, so on x86 we have:
>>
>> X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
>> independent, not that it doesn't stop in C states and similar fun stuff.
>>
>> X86_FEATURE_TSC_RELIABLE, which IIRC should indicate the TSC is constant
>> and synced between cores.
>>
> Fun, we also have:
>
> X86_FEATURE_NONSTOP_TSC, which states the thing doesn't stop in C
> states.
>

All of them? I though tsc stops in some mwait deep REM sleep thing.

So what do we need? test for both TSC_RELIABLE and NONSTOP_TSC? IMO
TSC_RELIABLE should imply NONSTOP_TSC.

--
error compiling committee.c: too many arguments to function

== 8 of 18 ==
Date: Mon, Apr 19 2010 4:00 am
From: Peter Zijlstra

On Mon, 2010-04-19 at 13:53 +0300, Avi Kivity wrote:
> On 04/19/2010 01:49 PM, Peter Zijlstra wrote:
> >
> >> Right, so on x86 we have:
> >>
> >> X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
> >> independent, not that it doesn't stop in C states and similar fun stuff.
> >>
> >> X86_FEATURE_TSC_RELIABLE, which IIRC should indicate the TSC is constant
> >> and synced between cores.
> >>
> > Fun, we also have:
> >
> > X86_FEATURE_NONSTOP_TSC, which states the thing doesn't stop in C
> > states.
> >
>
> All of them? I though tsc stops in some mwait deep REM sleep thing.

The idea is that TSC will not stop ever (except s2r like stuff), not
sure about the actual implementation of the NONSTOP_TSC bit though.

> So what do we need? test for both TSC_RELIABLE and NONSTOP_TSC? IMO
> TSC_RELIABLE should imply NONSTOP_TSC.

Yeah, I think RELIABLE does imply NONSTOP and CONSTANT, but NONSTOP &&
CONSTANT does not make RELIABLE.

== 9 of 18 ==
Date: Mon, Apr 19 2010 4:00 am
From: Avi Kivity

On 04/19/2010 01:51 PM, Peter Zijlstra wrote:
>
>
>>> Right, so on x86 we have:
>>>
>>> X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
>>> independent, not that it doesn't stop in C states and similar fun stuff.
>>>
>>> X86_FEATURE_TSC_RELIABLE, which IIRC should indicate the TSC is constant
>>> and synced between cores.
>>>
>>>
>>>
>> Sockets and boards too? (IOW, how reliable is TSC_RELIABLE)?
>>
> Not sure, IIRC we clear that when the TSC sync test fails, eg when we
> mark the tsc clocksource unusable.
>

Worrying. By the time we detect this the guest may already have gotten
confused by clocks going backwards.

--
error compiling committee.c: too many arguments to function

== 10 of 18 ==
Date: Mon, Apr 19 2010 4:00 am
From: Peter Zijlstra

On Mon, 2010-04-19 at 13:49 +0300, Avi Kivity wrote:
> On 04/19/2010 01:46 PM, Peter Zijlstra wrote:
> > On Sat, 2010-04-17 at 21:48 +0300, Avi Kivity wrote:
> >
> >>> After this patch is applied, I don't see a single warp in time during 5 days
> >>> of execution, in any of the machines I saw them before.
> >>>
> >>>
> >>>
> >> Please define a cpuid bit that makes this optional. When we eventually
> >> enable it in the future, it will allow a wider range of guests to enjoy it.
> >>
> > Right, so on x86 we have:
> >
> > X86_FEATURE_CONSTANT_TSC, which only states that TSC is frequency
> > independent, not that it doesn't stop in C states and similar fun stuff.
> >
> > X86_FEATURE_TSC_RELIABLE, which IIRC should indicate the TSC is constant
> > and synced between cores.
> >
> >
>
> Sockets and boards too? (IOW, how reliable is TSC_RELIABLE)?

Not sure, IIRC we clear that when the TSC sync test fails, eg when we
mark the tsc clocksource unusable.

== 11 of 18 ==
Date: Mon, Apr 19 2010 4:00 am
From: Peter Zijlstra

On Mon, 2010-04-19 at 13:47 +0300, Avi Kivity wrote:
> On 04/19/2010 01:43 PM, Peter Zijlstra wrote:
> >
> >>>
> >>>> +
> >>>> cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
> >>>> {
> >>>> struct pvclock_shadow_time shadow;
> >>>> unsigned version;
> >>>> cycle_t ret, offset;
> >>>> + u64 last;
> >>>>
> >>>>
> >>>> + do {
> >>>> + last = last_value;
> >>>>
> >>> Otherwise, this assignment can see a partial update.
> >>>
> >> On a 32-bit guest, that is.
> >>
> > Right, do bear in mind that the x86 implementation of atomic64_read() is
> > terrifyingly expensive, it is better to not do that read and simply use
> > the result of the cmpxchg.
> >
> >
>
> atomic64_read() _is_ cmpxchg64b. Are you thinking of some clever
> implementation for smp i386?

No, what I was suggesting was to rewrite that loop no to need the
initial read but use the cmpxchg result of the previous iteration.

Something like:

u64 last = 0;

/* more stuff */

do {
if (ret < last)
return last;
last = cmpxchg64(&last_value, last, ret);
} while (last != ret);

That only has a single cmpxchg8 in there per loop instead of two
(avoiding the atomic64_read() one).

== 12 of 18 ==
Date: Mon, Apr 19 2010 4:00 am
From: Avi Kivity

On 04/19/2010 01:39 PM, Peter Zijlstra wrote:
> On Fri, 2010-04-16 at 13:36 -0700, Jeremy Fitzhardinge wrote:
>
>>> + do {
>>> + last = last_value;
>>>
>>>
>> Does this need a barrier() to prevent the compiler from re-reading
>> last_value for the subsequent lines? Otherwise "(ret< last)" and
>> "return last" could execute with different values for "last".
>>
>>
> ACCESS_ONCE() is your friend.
>

I think it's implied with atomic64_read().

--
error compiling committee.c: too many arguments to function

== 13 of 18 ==
Date: Mon, Apr 19 2010 4:10 am
From: Peter Zijlstra

On Mon, 2010-04-19 at 13:50 +0300, Avi Kivity wrote:
> On 04/19/2010 01:39 PM, Peter Zijlstra wrote:
> > On Fri, 2010-04-16 at 13:36 -0700, Jeremy Fitzhardinge wrote:
> >
> >>> + do {
> >>> + last = last_value;
> >>>
> >>>
> >> Does this need a barrier() to prevent the compiler from re-reading
> >> last_value for the subsequent lines? Otherwise "(ret< last)" and
> >> "return last" could execute with different values for "last".
>
> > ACCESS_ONCE() is your friend.
> >
>
> I think it's implied with atomic64_read().

Yes it would be. I was merely trying to point out that

last = ACCESS_ONCE(last_value);

Is a narrower way of writing:

last = last_value;
barrier();

In that it need not clobber all memory locations and makes it instantly
clear what we want the barrier for.

== 14 of 18 ==
Date: Mon, Apr 19 2010 4:20 am
From: Avi Kivity

On 04/19/2010 01:56 PM, Peter Zijlstra wrote:
>
>
>>> Right, do bear in mind that the x86 implementation of atomic64_read() is
>>> terrifyingly expensive, it is better to not do that read and simply use
>>> the result of the cmpxchg.
>>>
>>>
>>>
>> atomic64_read() _is_ cmpxchg64b. Are you thinking of some clever
>> implementation for smp i386?
>>
>
> No, what I was suggesting was to rewrite that loop no to need the
> initial read but use the cmpxchg result of the previous iteration.
>
> Something like:
>
> u64 last = 0;
>
> /* more stuff */
>
> do {
> if (ret< last)
> return last;
> last = cmpxchg64(&last_value, last, ret);
> } while (last != ret);
>
> That only has a single cmpxchg8 in there per loop instead of two
> (avoiding the atomic64_read() one).
>

Still have two cmpxchgs in the common case. The first iteration will
fail, fetching last_value, the second will work.

It will be better when we have contention, though, so it's worthwhile.

--
error compiling committee.c: too many arguments to function

== 15 of 18 ==
Date: Mon, Apr 19 2010 4:20 am
From: Peter Zijlstra

On Mon, 2010-04-19 at 14:13 +0300, Avi Kivity wrote:
> On 04/19/2010 01:56 PM, Peter Zijlstra wrote:
> >
> >
> >>> Right, do bear in mind that the x86 implementation of atomic64_read() is
> >>> terrifyingly expensive, it is better to not do that read and simply use
> >>> the result of the cmpxchg.
> >>>
> >>>
> >>>
> >> atomic64_read() _is_ cmpxchg64b. Are you thinking of some clever
> >> implementation for smp i386?
> >>
> >
> > No, what I was suggesting was to rewrite that loop no to need the
> > initial read but use the cmpxchg result of the previous iteration.
> >
> > Something like:
> >
> > u64 last = 0;
> >
> > /* more stuff */
> >
> > do {
> > if (ret< last)
> > return last;
> > last = cmpxchg64(&last_value, last, ret);
> > } while (last != ret);
> >
> > That only has a single cmpxchg8 in there per loop instead of two
> > (avoiding the atomic64_read() one).
> >
>
> Still have two cmpxchgs in the common case. The first iteration will
> fail, fetching last_value, the second will work.
>
> It will be better when we have contention, though, so it's worthwhile.

Right, another option is to put the initial read outside of the loop,
that way you'll have the best of all cases, a single LOCK'ed op in the
loop, and only a single LOCK'ed op for the fast path on sensible
architectures ;-)

last = atomic64_read(&last_value);
do {
if (ret < last)
return last;
last = atomic64_cmpxchg(&last_value, last, ret);
} while (unlikely(last != ret));

Or so.

== 16 of 18 ==
Date: Mon, Apr 19 2010 4:20 am
From: Avi Kivity

On 04/19/2010 02:05 PM, Peter Zijlstra wrote:
>>
>>> ACCESS_ONCE() is your friend.
>>>
>>>
>> I think it's implied with atomic64_read().
>>
> Yes it would be. I was merely trying to point out that
>
> last = ACCESS_ONCE(last_value);
>
> Is a narrower way of writing:
>
> last = last_value;
> barrier();
>
> In that it need not clobber all memory locations and makes it instantly
> clear what we want the barrier for.
>

Oh yes, just trying to avoid a patch with both atomic64_read() and
ACCESS_ONCE().

--
error compiling committee.c: too many arguments to function

== 17 of 18 ==
Date: Mon, Apr 19 2010 4:40 am
From: Avi Kivity

On 04/19/2010 01:59 PM, Peter Zijlstra wrote:
>
>> So what do we need? test for both TSC_RELIABLE and NONSTOP_TSC? IMO
>> TSC_RELIABLE should imply NONSTOP_TSC.
>>
> Yeah, I think RELIABLE does imply NONSTOP and CONSTANT, but NONSTOP&&
> CONSTANT does not make RELIABLE.
>

The manual says:

> 16.11.1 Invariant TSC
>
> The time stamp counter in newer processors may support an enhancement,
> referred
> to as invariant TSC. Processor's support for invariant TSC is indicated by
> CPUID.80000007H:EDX[8].
> The invariant TSC will run at a constant rate in all ACPI P-, C-. and
> T-states. This is
> the architectural behavior moving forward. On processors with
> invariant TSC
> support, the OS may use the TSC for wall clock timer services (instead
> of ACPI or
> HPET timers). TSC reads are much more efficient and do not incur the
> overhead
> associated with a ring transition or access to a platform resource.

and this maps to NONSTOP, so I think we're fine.

--
error compiling committee.c: too many arguments to function

== 18 of 18 ==
Date: Mon, Apr 19 2010 4:50 am
From: Avi Kivity

On 04/19/2010 02:19 PM, Peter Zijlstra wrote:
>
>> Still have two cmpxchgs in the common case. The first iteration will
>> fail, fetching last_value, the second will work.
>>
>> It will be better when we have contention, though, so it's worthwhile.
>>
> Right, another option is to put the initial read outside of the loop,
> that way you'll have the best of all cases, a single LOCK'ed op in the
> loop, and only a single LOCK'ed op for the fast path on sensible
> architectures ;-)
>
> last = atomic64_read(&last_value);
> do {
> if (ret< last)
> return last;
> last = atomic64_cmpxchg(&last_value, last, ret);
> } while (unlikely(last != ret));
>
> Or so.
>
>

Yes, looks optimal when !NONSTOP_TSC.

--
error compiling committee.c: too many arguments to function

==============================================================================
TOPIC: boot device order troubleshooting without an initrd
http://groups.google.com/group/linux.kernel/t/955739f060762d9e?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Apr 19 2010 3:50 am
From: skitching@apache.org

As it happens, I've been looking into this issue recently.
[Warning: kernel newbie speaking!]

Without an initrd, the options for the root= kernel parameters are only those supported in init/do_mount.c:
1. root=MAJOR:MINOR
2. root=integer where integer is MAJOR<<n + minor
3 root=/dev/xxx
(well, apart fron "mtd" and "ubi" options).

Unfortunately, all of these options are sensitive to hardware changes, ie device enumeration order. So I
think that right now the answer to your question is: no, you can't get what you want without an initrd.

And I doubt that changes to the linux device-enumeration code "to be consistent with the BIOS" would be accepted.

Perhaps one thing that could be reasonably easily supported is:
root=gptguid
where gptguid is the id of a partition on a GPT-formatted disk. With msdos partition tables, partitions do not
have unique identifiers; Windows does puts a 32-bit "windows nt disk signature" field in the MBR, which could
possibly be used but it isn't really standard. However the GPT format (part of the EFI standard) mandates a
unique GUID be assigned to every partition which sounds like an excellent way to specify the location of the
root fs.

I *think* that it would be a matter of enhancing the "struct hd_struct" held by "struct gendisk" to store this
info when scanning a GPT partition table, then enhancing do_mount.c to check the root param against these values.

See: http://en.wikipedia.org/wiki/GUID_Partition_Table

Thoughts?

If this sounds sane to people, I would be keen to have a go at implementing this. Are there any specific
people or lists that should be cc'd when discussing this?

Regards, Simon

==============================================================================
TOPIC: Good Day
http://groups.google.com/group/linux.kernel/t/d3651a178bac4d78?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Apr 19 2010 4:30 am
From: Liu Tai Ling

Good Day,
I have a Business Proposal of $21,300,000.00 for you to handle with me from my bank.please contact me on {lingtai25@yahoo.com.hk} with your Full names,occupation,private phone number,current residential address.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: hid: Add mappings for a few keys found on Logitech MX3200
http://groups.google.com/group/linux.kernel/t/36068c38d2acbc02?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Apr 19 2010 4:30 am
From: Jiri Kosina

On Fri, 16 Apr 2010, Lorenzo Castelli wrote:

> The keys are added to the generic wireless mappings in case other
> keyboards use them. Note that the product ID for the MX3200 is the same
> as USB_DEVICE_ID_S510_RECEIVER_2.

Applied. thanks.

--
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: CFQ read performance regression
http://groups.google.com/group/linux.kernel/t/f106eaf14f59195d?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Apr 19 2010 4:50 am
From: Miklos Szeredi

Hi Corrado,

On Sat, 2010-04-17 at 14:46 +0200, Corrado Zoccolo wrote:
> I don't think this is related to CFQ. I've made a graph of the
> accessed (read) sectors (see attached).
> You can see that the green cloud (2.6.16) is much more concentrated,
> while the red one (2.6.32) is split in two, and you can better
> recognize the different lines.
> This means that the FS put more distance between the blocks of the
> files written by the tio threads, and the read time is therefore
> impacted, since the disk head has to perform longer seeks. On the
> other hand, if you read those files sequentially with a single thread,
> the performance may be better with the new layout, so YMMV. When
> testing 2.6.32 and up, you should consider testing also with
> low_latency setting disabled, since tuning for latency can negatively
> affect throughput.

low_latency is set to zero in all tests.

The layout difference doesn't explain why setting the scheduler to
"noop" consistently speeds up read throughput in 8-thread tiobench to
almost twice. This fact alone pretty clearly indicates that the I/O
scheduler is the culprit.

There are other indications, see the attached btt output for both
traces. From there it appears that 2.6.16 does more and longer seeks,
yet it's getting an overall better performance.

I've also tested with plain "dd" instead of tiobench where the
filesystem layout stayed exactly the same between tests. Still the
speed difference is there.

Thanks,
Miklos

************************************************************************
btt output for 2.6.16:
==================== All Devices ====================

ALL MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------

Q2Q 0.000000047 0.000854417 1.003550405 67465
Q2G 0.000000458 0.000001211 0.000123527 46062
G2I 0.000000123 0.000001815 0.000494517 46074
Q2M 0.000000186 0.000001798 0.000010296 21404
I2D 0.000000162 0.000158001 0.040794333 46062
M2D 0.000000878 0.000133130 0.040585566 21404
D2C 0.000053870 0.023778266 0.234154543 67466
Q2C 0.000056746 0.023931014 0.234176000 67466

==================== Device Overhead ====================

DEV | Q2G G2I Q2M I2D D2C
---------- | --------- --------- --------- --------- ---------
( 8, 64) | 0.0035% 0.0052% 0.0024% 0.4508% 99.3617%
---------- | --------- --------- --------- --------- ---------
Overall | 0.0035% 0.0052% 0.0024% 0.4508% 99.3617%

==================== Device Merge Information ====================

DEV | #Q #D Ratio | BLKmin BLKavg BLKmax Total
---------- | -------- -------- ------- | -------- -------- -------- --------
( 8, 64) | 67466 46062 1.5 | 8 597 1024 27543688

==================== Device Q2Q Seek Information ====================

DEV | NSEEKS MEAN MEDIAN | MODE
---------- | --------------- --------------- --------------- | ---------------
( 8, 64) | 67466 866834.0 0 | 0(34558)
---------- | --------------- --------------- --------------- | ---------------
Overall | NSEEKS MEAN MEDIAN | MODE
Average | 67466 866834.0 0 | 0(34558)

==================== Device D2D Seek Information ====================

DEV | NSEEKS MEAN MEDIAN | MODE
---------- | --------------- --------------- --------------- | ---------------
( 8, 64) | 46062 1265503.9 0 | 0(13242)
---------- | --------------- --------------- --------------- | ---------------
Overall | NSEEKS MEAN MEDIAN | MODE
Average | 46062 1265503.9 0 | 0(13242)

==================== Plug Information ====================

DEV | # Plugs # Timer Us | % Time Q Plugged
---------- | ---------- ---------- | ----------------
( 8, 64) | 29271( 533) | 3.878105328%

DEV | IOs/Unp IOs/Unp(to)
---------- | ---------- ----------
( 8, 64) | 19.2 19.7
---------- | ---------- ----------
Overall | IOs/Unp IOs/Unp(to)
Average | 19.2 19.7

==================== Active Requests At Q Information ====================

DEV | Avg Reqs @ Q
---------- | -------------
( 8, 64) | 0.8

==================== I/O Active Period Information ====================

DEV | # Live Avg. Act Avg. !Act % Live
---------- | ---------- ------------- ------------- ------
( 8, 64) | 545 0.100012237 0.005766640 94.56
---------- | ---------- ------------- ------------- ------
Total Sys | 545 0.100012237 0.005766640 94.56

************************************************************************
btt output for 2.6.32:

==================== All Devices ====================

ALL MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------

Q2Q 0.000000279 0.001710581 1.803934429 69429
Q2G 0.000000908 0.001798735 23.144764798 54940
S2G 0.022460311 6.581680621 23.144763751 15
G2I 0.000000628 0.000001576 0.000120409 54942
Q2M 0.000000628 0.000001611 0.000013201 14490
I2D 0.000000768 0.289812035 86.820205789 54940
M2D 0.000005518 0.098208187 0.794441158 14490
D2C 0.000173141 0.008056256 0.219516385 69430
Q2C 0.000179077 0.259305605 86.820559403 69430

==================== Device Overhead ====================

DEV | Q2G G2I Q2M I2D D2C
---------- | --------- --------- --------- --------- ---------
( 8, 64) | 0.5489% 0.0005% 0.0001% 88.4394% 3.1069%
---------- | --------- --------- --------- --------- ---------
Overall | 0.5489% 0.0005% 0.0001% 88.4394% 3.1069%

==================== Device Merge Information ====================

DEV | #Q #D Ratio | BLKmin BLKavg BLKmax Total
---------- | -------- -------- ------- | -------- -------- -------- --------
( 8, 64) | 69430 54955 1.3 | 8 520 2048 28614984

==================== Device Q2Q Seek Information ====================

DEV | NSEEKS MEAN MEDIAN | MODE
---------- | --------------- --------------- --------------- | ---------------
( 8, 64) | 69430 546377.3 0 | 0(50235)
---------- | --------------- --------------- --------------- | ---------------
Overall | NSEEKS MEAN MEDIAN | MODE
Average | 69430 546377.3 0 | 0(50235)

==================== Device D2D Seek Information ====================

DEV | NSEEKS MEAN MEDIAN | MODE
---------- | --------------- --------------- --------------- | ---------------
( 8, 64) | 54955 565286.3 0 | 0(37535)
---------- | --------------- --------------- --------------- | ---------------
Overall | NSEEKS MEAN MEDIAN | MODE
Average | 54955 565286.3 0 | 0(37535)

==================== Plug Information ====================

DEV | # Plugs # Timer Us | % Time Q Plugged
---------- | ---------- ---------- | ----------------
( 8, 64) | 2310( 0) | 0.049353257%

DEV | IOs/Unp IOs/Unp(to)
---------- | ---------- ----------
( 8, 64) | 7.3 0.0
---------- | ---------- ----------
Overall | IOs/Unp IOs/Unp(to)
Average | 7.3 0.0

==================== Active Requests At Q Information ====================

DEV | Avg Reqs @ Q
---------- | -------------
( 8, 64) | 132.8

==================== I/O Active Period Information ====================

DEV | # Live Avg. Act Avg. !Act % Live
---------- | ---------- ------------- ------------- ------
( 8, 64) | 4835 0.023848998 0.000714665 97.09
---------- | ---------- ------------- ------------- ------
Total Sys | 4835 0.023848998 0.000714665 97.09

==============================================================================
TOPIC: Process-shared futexes on hugepages puts the kernel in an infinite loop
in 2.6.32.11; is this fixed now?
http://groups.google.com/group/linux.kernel/t/e9a305f09a39640e?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Apr 19 2010 4:50 am
From: Mel Gorman

On Fri, Apr 16, 2010 at 10:27:48PM +0200, Peter Zijlstra wrote:
> On Fri, 2010-04-16 at 23:45 +0800, r6144 wrote:
> > Hello all,
> >
> > I'm having an annoying kernel bug regarding huge pages in Fedora 12:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=552257
> >
> > Basically I want to use huge pages in a multithreaded number crunching
> > program, which happens to use process-shared semaphores (because fftw
> > does it). The futex for the semaphore ends up lying on a huge page, and
> > I then get an endless loop in get_futex_key(), apparently because the
> > anonymous huge page containing the futex does not have a page->mapping.
> > A test case is provided in the above link.
> >
> > I reported the bug to Fedora bugzilla months ago, but haven't received
> > any feedback yet.
>
> No, it works much better if you simply mail LKML and CC people who work
> on the code in question ;-)
>
> > The Fedora kernel is based on 2.6.32.11, and a
> > cursory glance at the 2.6.34-rc3 source does not yield any relevant
> > change.
> >
> > So, could anyone tell me if the current mainline kernel might act better
> > in this respect, before I get around to compiling it?
>
> Right, so I had a quick chat with Mel, and it appears MAP_PRIVATE
> hugetlb pages don't have their page->mapping set.
>
> I guess something like the below might work, but I'd really rather not
> add hugetlb knowledge to futex.c. Does anybody else have a better idea?
> Maybe create something similar to an anon_vma for hugetlb pages?
>

anon_vma for hugetlb pages sounds overkill, what would it gain? In this
context, futex only appears to distinguish between whether the
references are private or shared.

Looking at the hugetlbfs code, I can't see a place where it actually cares
about the mapping as such. It's used to find shared pages in the page cache
(but not in the LRU) that are backed by the hugetlbfs file. For hugetlbfs
though, the mapping is mostly kept in page->private for reservation accounting
purposes.

I can't think of other parts of the VM that touch the mapping if the
page is managed by hugetlbfs so the following patch should also work but
without futex having hugetlbfs-awareness. What do you think? Maybe for
safety, it would be better to make the mapping some obvious poison bytes
or'd with PAGE_MAPPING_ANON so an oops will be more obvious?

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6034dc9..57a5faa 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -546,6 +546,7 @@ static void free_huge_page(struct page *page)

mapping = (struct address_space *) page_private(page);
set_page_private(page, 0);
+ page->mapping = NULL;
BUG_ON(page_count(page));
INIT_LIST_HEAD(&page->lru);

@@ -2447,8 +2448,10 @@ retry:
spin_lock(&inode->i_lock);
inode->i_blocks += blocks_per_huge_page(h);
spin_unlock(&inode->i_lock);
- } else
+ } else {
lock_page(page);
+ page->mapping = (struct address_space *)PAGE_MAPPING_ANON;
+ }
}

/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Monday, April 19, 2010

linux.kernel - 26 new messages in 8 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts