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

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

Today's topics:

* slub: ARCH_SLAB_MINALIGN defaults to 8 on x86_32. is this too big? - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/90562c9ef16cf2a0?hl=en
* HID: make raw reports possible for both feature and output reports - 4
messages, 1 author
http://groups.google.com/group/linux.kernel/t/24254d069a593af0?hl=en
* [PATCH] perf_events, x86: PEBS support - 4 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/0acdc85baea49653?hl=en
* sysfs_chmod_file() broken in 2.6.33-rc4-git6 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/2de5f9020ce2b995?hl=en
* Improving OOM killer - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/389db2dcf6479d30?hl=en
* platform_driver_register: warn if probe is in .init.text - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/7db9be36a46d6f4f?hl=en
* regression in 2.6.27.45 with usb and suspend-to-disk - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f18f89f344fa881c?hl=en
* USB mass storage and ARM cache coherency - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/68938cdf1fa061a9?hl=en
* bitops: compile time optimization for hweight_long(CONSTANT) - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/f58ac10e7917a328?hl=en
* checkpatch.pl: Add warning on non #define continuation lines - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/f7008b136135527c?hl=en
* arm: mxc: TrustZone interrupt controller (TZIC) for i.MX5 family - 2
messages, 1 author
http://groups.google.com/group/linux.kernel/t/281ca1a532ca6d76?hl=en
* Unreachable block in Kernel Code (CONFIG_SSB_SDIO) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/66b3018f2aa264bc?hl=en
* [mmotm-2010-02-01-16-25] Fix wrong accouting of anon and file - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/f35e6a47485570bf?hl=en
* [RFC] 512K readahead size with thrashing safe readahead - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/96ba73a9249e5c25?hl=en
* agpgart-amd64 not initialized in 2.6.33-rc5 if iommu=allowed in kernel
command line - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b9c35e386ebb7a6d?hl=en
* mfd: Add support for the timberdale FPGA. - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d01182830d6bf0f5?hl=en
* Re-enabling non-GPL driver access to disk partition information - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/cdc0617079a6d776?hl=en

==============================================================================
TOPIC: slub: ARCH_SLAB_MINALIGN defaults to 8 on x86_32. is this too big?
http://groups.google.com/group/linux.kernel/t/90562c9ef16cf2a0?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 6:30 am
From: Richard Kennedy

Hi all,

slub.c sets the default value of ARCH_SLAB_MINALIGN to sizeof(unsigned
long long) if the architecture didn't already override it.

And as x86_32 doesn't set a value this means that slab objects get
aligned to 8 bytes, potentially wasting 4 bytes per object. Slub forces
objects to be aligned to sizeof(void *) anyway, but I don't see that
there is any need for it to be 8 on 32bits.

I'm working on a patch to pack more buffer_heads into each kmem_cache
slab page.
On 32 bits the structure size is 52 bytes and with the alignment applied
I end up with a slab of 73 x 56 byte objects. However, if the minimum
alignment was sizeof(void *) then I'd get 78 x 52 byte objects. So there
is quite a memory saving to be had in changing this.

Can I define a ARCH_SLAB_MINALIGN in x86_64 to sizeof(void *) ?
or would it be ok to change the default in slub.c to sizeof(void *) ?

Or am I missing something ?

regards
Richard

--
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: make raw reports possible for both feature and output reports
http://groups.google.com/group/linux.kernel/t/24254d069a593af0?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Feb 3 2010 6:40 am
From: Jiri Kosina

On Wed, 3 Feb 2010, Marcel Holtmann wrote:

> > In commit 2da31939a42 ("Bluetooth: Implement raw output support for HIDP
> > layer"), support for Bluetooth hid_output_raw_report was added, but it
> > pushes the data to the intr socket instead of the ctrl one. This has been
> > fixed by 6bf8268f9a91f1 ("Bluetooth: Use the control channel for raw HID reports")
> >
> > Still, it is necessary to distinguish whether the report in question should be
> > either FEATURE or OUTPUT. For this, we have to extend the generic HID API,
> > so that hid_output_raw_report() callback provides means to specify this
> > value so that it can be passed down to lower level hardware drivers (currently
> > Bluetooth and USB).
> >
> > Based on original patch by Bastien Nocera <hadess@hadess.net>
> > Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> > ---
> > drivers/hid/hidraw.c | 2 +-
> > drivers/hid/usbhid/hid-core.c | 5 +++--
> > include/linux/hid.h | 2 +-
> > net/bluetooth/hidp/core.c | 13 ++++++++++---
> > 4 files changed, 15 insertions(+), 7 deletions(-)
>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
>
> > -static int hidp_output_raw_report(struct hid_device *hid, unsigned char *data, size_t count)
> > +static int hidp_output_raw_report(struct hid_device *hid, unsigned char *data, size_t count,
> > + unsigned char report_type)
> > {
> > - if (hidp_send_ctrl_message(hid->driver_data,
> > - HIDP_TRANS_SET_REPORT | HIDP_DATA_RTYPE_FEATURE,
> > + if (report_type == HID_FEATURE_REPORT)
> > + report_type = HIDP_TRANS_SET_REPORT | HIDP_DATA_RTYPE_FEATURE;
> > + else if (report_type == HID_OUTPUT_REPORT)
> > + report_type = HIDP_TRANS_DATA | HIDP_DATA_RTYPE_OUPUT;
> > + else
> > + return -EINVAL;
>
> If you wanna be a little bit more readable, then using a switch
> statement helps instead of else if. Just my 2 cents.

I have converted this to switch, added your Acked-by and queued in my
tree.

Thanks Marcel.

--
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/

== 2 of 4 ==
Date: Wed, Feb 3 2010 6:50 am
From: Jiri Kosina

On Wed, 3 Feb 2010, Marcel Holtmann wrote:

> Hi Jiri,
>
> > The hid-wacom driver required user-space to poke at the tablet
> > to make it send data about the cursor location.
> >
> > This patch makes it do the same thing but in the kernel.
> >
> > Signed-off-by: Bastien Nocera <hadess@hadess.net>
> > Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
>
> >
> > + /* Set Wacom mode2 */
> > + rep_data[0] = 0x03; rep_data[1] = 0x00;
> > + limit =3;
>
> Small nitpick here. The space after = is missing ;)

Fixed and applied. Thank you.

== 3 of 4 ==
Date: Wed, Feb 3 2010 6:50 am
From: Jiri Kosina

On Wed, 3 Feb 2010, Marcel Holtmann wrote:

> Hi Jiri,
>
> > Now that hid_output_raw_report works, port the PS3 Sixaxis
> > Bluetooth quirk from user-space, into kernel-space.
> >
> > Signed-off-by: Bastien Nocera <hadess@hadess.net>
> > Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>
> Acked-by: Marcel Holtmann <marcel@holtmann.org>
>
> > - ret = sony_set_operational(hdev);
> > + if (hdev->bus == BUS_USB)
> > + ret = sony_set_operational(hdev);
> > + else if (hdev->bus == BUS_BLUETOOTH)
> > + ret = sony_set_operational_bt(hdev);
> > + else
> > + ret = 0;
> > +
>
> I would do sony_set_operational_usb() and sony_set_operational_bt() and
> also turn this into a switch statement for better readability.

Fixed and applied. Thanks,

== 4 of 4 ==
Date: Wed, Feb 3 2010 7:00 am
From: Jiri Kosina

On Fri, 29 Jan 2010, Ping Cheng wrote:

> + rep_data[0] = 0x03; rep_data[1] = 0x00;
> + limit =3;
> + do {
> + ret = hdev->hid_output_raw_report(hdev, rep_data, 2,
> + HID_FEATURE_REPORT);
> + } while (ret < 0 && limit-- > 0);
>
>
> hdev->hid_output_raw_report error is not a hard failure, i.e., the following four lines are unnecessay. We can continue with the
> rest of the code.
>
> + if (ret < 0) {
> + dev_err(&hdev->dev, "failed to poke device #1, %d\n", ret);
> + goto err_free;
> + }
> +
> + /* 0x06 - high reporting speed, 0x05 - low speed */
> + rep_data[0] = 0x06; rep_data[1] = 0x00;
> + limit = 3;
> + do {
> + ret = hdev->hid_output_raw_report(hdev, rep_data, 2,
> + HID_FEATURE_REPORT);
> + } while (ret < 0 && limit-- > 0);
>
>
> Same comments apply here. "/* Note that if query fails it is not a hard failure */" is the comments we use in the corresponding
> Wacom USB driver, wacom_sys.c

Thanks for the feedback. I have queued the patch below on top of all the
other changes.

From: Jiri Kosina <jkosina@suse.cz>
Subject: [PATCH] HID: make Wacom modesetting failures non-fatal

With Wacom tablet mode-setting moved from userspace into kernel,
we don't have to consider failures of device queries through the
_raw callback as hard failure, as the driver can safely continue
anyway.

This is consistent with the current USB driver in wacom_sys.c

Reported-by: Ping Cheng <pinglinux@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-wacom.c | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/hid/hid-wacom.c b/drivers/hid/hid-wacom.c
index b8778db..8d3b46f 100644
--- a/drivers/hid/hid-wacom.c
+++ b/drivers/hid/hid-wacom.c
@@ -181,6 +181,11 @@ static int wacom_probe(struct hid_device *hdev,
goto err_free;
}

+ /*
+ * Note that if the raw queries fail, it's not a hard failure and it
+ * is safe to continue
+ */
+
/* Set Wacom mode2 */
rep_data[0] = 0x03; rep_data[1] = 0x00;
limit = 3;
@@ -188,10 +193,8 @@ static int wacom_probe(struct hid_device *hdev,
ret = hdev->hid_output_raw_report(hdev, rep_data, 2,
HID_FEATURE_REPORT);
} while (ret < 0 && limit-- > 0);
- if (ret < 0) {
- dev_err(&hdev->dev, "failed to poke device #1, %d\n", ret);
- goto err_free;
- }
+ if (ret < 0)
+ dev_warn(&hdev->dev, "failed to poke device #1, %d\n", ret);

/* 0x06 - high reporting speed, 0x05 - low speed */
rep_data[0] = 0x06; rep_data[1] = 0x00;
@@ -200,10 +203,8 @@ static int wacom_probe(struct hid_device *hdev,
ret = hdev->hid_output_raw_report(hdev, rep_data, 2,
HID_FEATURE_REPORT);
} while (ret < 0 && limit-- > 0);
- if (ret < 0) {
- dev_err(&hdev->dev, "failed to poke device #2, %d\n", ret);
- goto err_free;
- }
+ if (ret < 0)
+ dev_warn(&hdev->dev, "failed to poke device #2, %d\n", ret);

hidinput = list_entry(hdev->inputs.next, struct hid_input, list);
input = hidinput->input;
--
1.6.4.2

==============================================================================
TOPIC: [PATCH] perf_events, x86: PEBS support
http://groups.google.com/group/linux.kernel/t/0acdc85baea49653?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Feb 3 2010 6:40 am
From: Stephane Eranian

On Wed, Feb 3, 2010 at 3:19 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-02-03 at 15:07 +0100, Stephane Eranian wrote:
>> >> The only improvement that PEBS provides is that you get an IP and the
>> >> machine state at retirement of an instruction that caused the event to
>> >> increment. Thus, the IP points to the next dynamic instruction. The instruction
>> >> is not the one that cause the P-th occurence of the event, if you set the
>> >> period to P. It is at P+N, where N cannot be predicted and varies depending
>> >> on the event and executed code. This introduces some bias in the samples..
>> >
>> > I'm not sure I follow, it records the next event after overflow, doesn't
>> > that make it P+1?
>> >
>> That is not what I wrote. I did not say if records at P+1. I said it records
>> at P+N, where N varies from sample to sample and cannot be predicted.
>> N is expressed in the unit of the sampling event.
>
> OK, so I'm confused.
>
> The manual says it arms the PEBS assist on overflow, and the PEBS thing
> will then record the next event. Which to me reads like P+1.
>
you are assuming arming is instantaneous.
--
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 4 ==
Date: Wed, Feb 3 2010 6:50 am
From: Peter Zijlstra

On Wed, 2010-02-03 at 15:30 +0100, Stephane Eranian wrote:
> On Wed, Feb 3, 2010 at 3:19 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Wed, 2010-02-03 at 15:07 +0100, Stephane Eranian wrote:
> >> >> The only improvement that PEBS provides is that you get an IP and the
> >> >> machine state at retirement of an instruction that caused the event to
> >> >> increment. Thus, the IP points to the next dynamic instruction. The instruction
> >> >> is not the one that cause the P-th occurence of the event, if you set the
> >> >> period to P. It is at P+N, where N cannot be predicted and varies depending
> >> >> on the event and executed code. This introduces some bias in the samples..
> >> >
> >> > I'm not sure I follow, it records the next event after overflow, doesn't
> >> > that make it P+1?
> >> >
> >> That is not what I wrote. I did not say if records at P+1. I said it records
> >> at P+N, where N varies from sample to sample and cannot be predicted.
> >> N is expressed in the unit of the sampling event.
> >
> > OK, so I'm confused.
> >
> > The manual says it arms the PEBS assist on overflow, and the PEBS thing
> > will then record the next event. Which to me reads like P+1.
> >
> you are assuming arming is instantaneous.

Yes I was, ok that stinks.

If only they would reset the counter on overflow instead of on record,
that would solve quite a few issues I imagine.

Then add IP to the actual instruction and you've got yourself a useful
tool :-)

== 3 of 4 ==
Date: Wed, Feb 3 2010 7:00 am
From: Stephane Eranian

On Wed, Feb 3, 2010 at 3:40 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, 2010-02-03 at 15:30 +0100, Stephane Eranian wrote:
>> On Wed, Feb 3, 2010 at 3:19 PM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Wed, 2010-02-03 at 15:07 +0100, Stephane Eranian wrote:
>> >> >> The only improvement that PEBS provides is that you get an IP and the
>> >> >> machine state at retirement of an instruction that caused the event to
>> >> >> increment. Thus, the IP points to the next dynamic instruction. The instruction
>> >> >> is not the one that cause the P-th occurence of the event, if you set the
>> >> >> period to P. It is at P+N, where N cannot be predicted and varies depending
>> >> >> on the event and executed code. This introduces some bias in the samples..
>> >> >
>> >> > I'm not sure I follow, it records the next event after overflow, doesn't
>> >> > that make it P+1?
>> >> >
>> >> That is not what I wrote. I did not say if records at P+1. I said it records
>> >> at P+N, where N varies from sample to sample and cannot be predicted.
>> >> N is expressed in the unit of the sampling event.
>> >
>> > OK, so I'm confused.
>> >
>> > The manual says it arms the PEBS assist on overflow, and the PEBS thing
>> > will then record the next event. Which to me reads like P+1.
>> >
>> you are assuming arming is instantaneous.
>
> Yes I was, ok that stinks.
>
PEBS is still very useful because it guarantees the state you capture
is at retirement of an instruction which caused the event.

PEBS also gets way more interesting on Nehalem because of the
ability to capture where cache misses occur. That's the load latency
feature. You need to support that.

I believe you would need to abstract this in a generic fashion so it
could be used on other architectures, such as AMD with IBS.

On Nehalem, it requires the following:

- only works if you sample on MEM_INST_RETIRED:LATENCY_ABOVE_THRESHOLD.

- the threshold must be programmed into a dedicated MSR. The extra
difficulty is that this MSR is shared between CPU when HT is on.

> If only they would reset the counter on overflow instead of on record,
> that would solve quite a few issues I imagine.
>
> Then add IP to the actual instruction and you've got yourself a useful
> tool :-)
>
>
--
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/

== 4 of 4 ==
Date: Wed, Feb 3 2010 7:20 am
From: Peter Zijlstra

On Wed, 2010-02-03 at 15:54 +0100, Stephane Eranian wrote:
>
> PEBS is still very useful because it guarantees the state you capture
> is at retirement of an instruction which caused the event.
>
> PEBS also gets way more interesting on Nehalem because of the
> ability to capture where cache misses occur. That's the load latency
> feature. You need to support that.

Simple things first. But yeah, we'll get to load-latency eventually.

> I believe you would need to abstract this in a generic fashion so it
> could be used on other architectures, such as AMD with IBS.

Right, Robert said he was working on IBS, I've still not made up my mind
on how to represent IBS properly, its a bit of a weird thing.

> On Nehalem, it requires the following:
>
> - only works if you sample on MEM_INST_RETIRED:LATENCY_ABOVE_THRESHOLD.

Yeah, and then you get to decode the data source thingy, not really a
nice interface. Also, it mostly contains L3 information, not L2/L1.

> - the threshold must be programmed into a dedicated MSR. The extra
> difficulty is that this MSR is shared between CPU when HT is on.

Lovely :/ One way is to program it to the lowest of the two and simply
discard events afterwards.

==============================================================================
TOPIC: sysfs_chmod_file() broken in 2.6.33-rc4-git6
http://groups.google.com/group/linux.kernel/t/2de5f9020ce2b995?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 6:40 am
From: Greg KH

On Wed, Feb 03, 2010 at 09:11:38AM +0100, Jean Delvare wrote:
> On Thu, 21 Jan 2010 20:19:13 -0800, Greg KH wrote:
> > On Wed, Jan 20, 2010 at 04:00:08PM +0100, Jean Delvare wrote:
> > > On Wed, 20 Jan 2010 06:01:02 -0800, Eric W. Biederman wrote:
> > > > Does this fix your issue?
> > > >
> > > > Eric
> > > >
> > > >
> > > > diff --git a/fs/sysfs/inode.c b/fs/sysfs/inode.c
> > > > index 220b758..6a06a1d 100644
> > > > --- a/fs/sysfs/inode.c
> > > > +++ b/fs/sysfs/inode.c
> > > > @@ -81,24 +81,23 @@ int sysfs_sd_setattr(struct sysfs_dirent *sd, struct iattr * iattr)
> > > > if (!sd_attrs)
> > > > return -ENOMEM;
> > > > sd->s_iattr = sd_attrs;
> > > > - } else {
> > > > - /* attributes were changed at least once in past */
> > > > - iattrs = &sd_attrs->ia_iattr;
> > > > -
> > > > - if (ia_valid & ATTR_UID)
> > > > - iattrs->ia_uid = iattr->ia_uid;
> > > > - if (ia_valid & ATTR_GID)
> > > > - iattrs->ia_gid = iattr->ia_gid;
> > > > - if (ia_valid & ATTR_ATIME)
> > > > - iattrs->ia_atime = iattr->ia_atime;
> > > > - if (ia_valid & ATTR_MTIME)
> > > > - iattrs->ia_mtime = iattr->ia_mtime;
> > > > - if (ia_valid & ATTR_CTIME)
> > > > - iattrs->ia_ctime = iattr->ia_ctime;
> > > > - if (ia_valid & ATTR_MODE) {
> > > > - umode_t mode = iattr->ia_mode;
> > > > - iattrs->ia_mode = sd->s_mode = mode;
> > > > - }
> > > > + }
> > > > + /* attributes were changed at least once in past */
> > > > + iattrs = &sd_attrs->ia_iattr;
> > > > +
> > > > + if (ia_valid & ATTR_UID)
> > > > + iattrs->ia_uid = iattr->ia_uid;
> > > > + if (ia_valid & ATTR_GID)
> > > > + iattrs->ia_gid = iattr->ia_gid;
> > > > + if (ia_valid & ATTR_ATIME)
> > > > + iattrs->ia_atime = iattr->ia_atime;
> > > > + if (ia_valid & ATTR_MTIME)
> > > > + iattrs->ia_mtime = iattr->ia_mtime;
> > > > + if (ia_valid & ATTR_CTIME)
> > > > + iattrs->ia_ctime = iattr->ia_ctime;
> > > > + if (ia_valid & ATTR_MODE) {
> > > > + umode_t mode = iattr->ia_mode;
> > > > + iattrs->ia_mode = sd->s_mode = mode;
> > > > }
> > > > return 0;
> > > > }
> > >
> > > Yes, this fixes my problem. Thanks for the fast fix!
> >
> > Great, Eric, care to resend this so that I can submit it for inclusion?
>
> Ping Eric, the patch is still not in Linus' tree.

Nor mine :)

Eric, care to send it to me?

thanks,

greg k-h
--
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: Improving OOM killer
http://groups.google.com/group/linux.kernel/t/389db2dcf6479d30?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 6:50 am
From: Rik van Riel

On 02/01/2010 05:02 PM, Lubos Lunak wrote:

> In other words, use VmRSS for measuring memory usage instead of VmSize, and
> remove child accumulating.

I agree with removing the child accumulating code. That code can
do a lot of harm with databases like postgresql, or cause the
system's main service (eg. httpd) to be killed when a broken cgi
script used up too much memory.

IIRC the child accumulating code was introduced to deal with
malicious code (fork bombs), but it makes things worse for the
(much more common) situation of a system without malicious
code simply running out of memory due to being very busy.

I have no strong opinion on using RSS vs VmSize.

--
All rights reversed.
--
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: Wed, Feb 3 2010 7:10 am
From: Minchan Kim

On Wed, 2010-02-03 at 17:55 +0530, Balbir Singh wrote:
> * Lubos Lunak <l.lunak@suse.cz> [2010-02-03 13:10:27]:
>
> > On Wednesday 03 of February 2010, Balbir Singh wrote:
> > > * Lubos Lunak <l.lunak@suse.cz> [2010-02-01 23:02:37]:
> > > > In other words, use VmRSS for measuring memory usage instead of VmSize,
> > > > and remove child accumulating.
> > >
> > > I am not sure of the impact of changing to RSS, although I've
> > > personally believed that RSS based accounting is where we should go,
> > > but we need to consider the following
> > >
> > > 1. Total VM provides data about potentially swapped pages,
> >
> > Yes, I've already updated my proposal in another mail to switch from VmSize
> > to VmRSS+InSwap. I don't know how to find out the second item in code, but at
> > this point of discussion that's just details.
> >

We have swap count with mm-count-swap-usage.patch by Kame in mmtom.

> I am yet to catch up with the rest of the thread. Thanks for heads up.
>
> > > overcommit,
> >
> > I don't understand how this matters. Overcommit is memory for which address
> > space has been allocated but not actual memory, right? Then that's exactly
> > what I'm claiming is wrong and am trying to reverse. Currently OOM killer
> > takes this into account because it uses VmSize, but IMO it shouldn't - if a
> > process does malloc(400M) but then it uses only a tiny fraction of that, in
> > the case of memory shortage killing that process does not solve anything in
> > practice.
>
> We have a way of tracking commmitted address space, which is more
> sensible than just allocating memory and is used for tracking
> overcommit. I was suggesting that, that might be a better approach.

Yes. It does make sense. At least total_vm doesn't care about
MAP_NORESERVE case. But unfortunately, it's a per CPU not per Process.

>
> >
> > > etc.
> > > 2. RSS alone is not sufficient, RSS does not account for shared pages,
> > > so we ideally need something like PSS.
> >
> > Just to make sure I understand what you mean with "RSS does not account for
> > shared pages" - you say that if a page is shared by 4 processes, then when
> > calculating badness for them, only 1/4 of the page should be counted for
> > each? Yes, I suppose so, that makes sense.
>
> Yes, that is what I am speaking of

I agree. If we want to make RSS with base of badness, it's one of things
we have to solve.

--
Kind regards,
Minchan Kim

==============================================================================
TOPIC: platform_driver_register: warn if probe is in .init.text
http://groups.google.com/group/linux.kernel/t/7db9be36a46d6f4f?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 7:10 am
From: Greg KH

On Wed, Feb 03, 2010 at 10:42:26AM +0100, Uwe Kleine-K?nig wrote:
> Hello,
>
> > > So can you please look into that before they are swapped out of your
> > > inbox the third(?) time?
> >
> > I think the video ones can be all in one patch, that makes it easier for
> > me to track and apply. Same goes for any others you can merge together.
> So I group by drivers/* and arch/*?

Sure, that would make it easier, right?

thanks,

==============================================================================
TOPIC: regression in 2.6.27.45 with usb and suspend-to-disk
http://groups.google.com/group/linux.kernel/t/f18f89f344fa881c?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 7:10 am
From: Alan Stern

On Wed, 3 Feb 2010, Corey Wright wrote:

> 2.6.27.45 will only suspend-to-disk once without rebooting. every attempt
> to suspend-to-disk after the first attempt results in "pm_op():
> usb_dev_freeze +0x0/0xa returns -16" and "PM: Device usb1 failed to freeze:
> error -16". reverting commit 4fbebe26d7a5eed6c1900bf2142b68af7df38462
> (http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=commit;h=4fbebe26d7a5eed6c1900bf2142b68af7df38462)
> fixes the problem.
>
> this problem exhibits itself on both a x86-64 desktop and i386 netbook
> (though the reverted commit was only tested on the x86-64 desktop). the
> affected computers are different architectures, different distributions
> (debian lenny vs ubuntu hardy), and different kernel configs (but unchanged
> since 2.6.27.23), so i am fairly certain this is a regression in 2.6.27.45
> and not the result of an environment change.
>
> i normally use the pm-hibernate command to suspend to disk, but to isolate
> the problem i used the kernel interfaces directly (as demonstrated in the
> transcript below).
>
> i can provide any other information necessary (eg .config, dmesg, lsusb)
> and i am willing to test patches.

Please build a kernel with CONFIG_USB_DEBUG enabled and post a dmesg
log showing the problem during the second hibernation attempt.

Alan Stern

==============================================================================
TOPIC: USB mass storage and ARM cache coherency
http://groups.google.com/group/linux.kernel/t/68938cdf1fa061a9?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 7:20 am
From: Alan Stern

On Tue, 2 Feb 2010, Andreas Mohr wrote:

> Any ideas? To my uncaring mind this would look like __flush_dcache_page()
> not being quite so happy with a NULL pointer that it is being served
> (although I haven't managed to precisely investigate yet where the
> dereferencing offset 0000041c is coming from).
>
> Yes, crash is reproducible (three times on boot already, although some bootup
> does make it successfully).
>
> My ehci-q.c has:
>
> if (usb_pipein(urb->pipe) && usb_pipetype(urb->pipe) != PIPE_CONTROL) {
> void *ptr;
> for (ptr = urb->transfer_buffer;
> ptr < urb->transfer_buffer + urb->transfer_buffer_length;
> ptr += PAGE_SIZE)
> flush_dcache_page(virt_to_page(ptr));
> }
>
> Hmm, OTOH this code seems to postulate that urb->transfer_buffer_length
> is that 0x41c from above...
> (IOW the code is simply missing an urb->transfer_buffer NULL check)
> OTOH there would also be the question whether flush_dcache_page() should
> have caught the NULL pointer input...
> And then there's the question whether urb->transfer_buffer is allowed to end
> up as NULL anyway...

Have you looked at the code in qh_urb_transaction() in ehci-q.c
involving this_sg_len and buf? It's quite possible that
urb->transfer_buffer is a NULL pointer and that the actual buffer is
not a contiguous set of pages -- but only if DMA is used.

Alan Stern

==============================================================================
TOPIC: bitops: compile time optimization for hweight_long(CONSTANT)
http://groups.google.com/group/linux.kernel/t/f58ac10e7917a328?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 7:20 am
From: Peter Zijlstra

On Wed, 2010-02-03 at 07:08 -0800, Andrew Morton wrote:
> On Wed, 3 Feb 2010 21:39:51 +0800 Wu Fengguang <fengguang.wu@intel.com> wrote:
>
> > Is there an official lowest GCC version that Linux supports?
>
> Documentation/Changes says gcc-3.2.

Anyway, its not like that macro I used isn't straight forward. Not much
a builtin can do better.

The only benefit the builtin has is possibly use machine popcnt
instructions but we already deal with that in the kernel.

== 2 of 2 ==
Date: Wed, Feb 3 2010 7:20 am
From: Andrew Morton

On Wed, 3 Feb 2010 21:39:51 +0800 Wu Fengguang <fengguang.wu@intel.com> wrote:

> Is there an official lowest GCC version that Linux supports?

Documentation/Changes says gcc-3.2.
--
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: checkpatch.pl: Add warning on non #define continuation lines
http://groups.google.com/group/linux.kernel/t/f7008b136135527c?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 7:20 am
From: Andy Whitcroft

> Does anyone know if Andy Whitcroft is still looking after checkpatch?

Yeah I am still about, just a lot behind on all things checkpatch. I am
going to be on a plane in the next couple of days and thats a good time
to get to the checkpatch backlog.

-apw
--
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: arm: mxc: TrustZone interrupt controller (TZIC) for i.MX5 family
http://groups.google.com/group/linux.kernel/t/281ca1a532ca6d76?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 7:20 am
From: Eric Miao

On Wed, Feb 3, 2010 at 5:24 AM, Amit Kucheria
<amit.kucheria@canonical.com> wrote:
> On 10 Feb 02, Eric Miao wrote:
>> Hi Amit,
>>
>> Just some nit-picking review comments, see below:
>>
>> On Tue, Feb 2, 2010 at 9:16 PM, Amit Kucheria
>> <amit.kucheria@canonical.com> wrote:
>> > Freescale i.MX51 processor uses a new interrupt controller. Add
>> > driver for TrustZone Interrupt Controller
>> >
>> > Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
>> > ---
>> > arch/arm/plat-mxc/Kconfig | 8 ++
>> > arch/arm/plat-mxc/Makefile | 3 +
>> > arch/arm/plat-mxc/tzic.c | 182 ++++++++++++++++++++++++++++++++++++++++++++
>> > 3 files changed, 193 insertions(+), 0 deletions(-)
>> > create mode 100644 arch/arm/plat-mxc/tzic.c
>> >
>> > diff --git a/arch/arm/plat-mxc/Kconfig b/arch/arm/plat-mxc/Kconfig
>> > index 8b0a1ee..59558c4 100644
>> > --- a/arch/arm/plat-mxc/Kconfig
>> > +++ b/arch/arm/plat-mxc/Kconfig
>> > @@ -62,6 +62,14 @@ config MXC_IRQ_PRIOR
>> > requirements for timing.
>> > Say N here, unless you have a specialized requirement.
>> >
>> > +config MXC_TZIC
>> > + bool "Enable TrustZone Interrupt Controller"
>> > + depends on ARCH_MX51
>>
>> This is the first patch of the base port, yet I cannot find any reference to
>> this ARCH_MX51, did you miss something?
>
> ARCH_MX51 is only introduced in the later patches that add the core i.MX5
> code. Since TZIC is not inherently dependent on i.MX5 (it's merely the first
> processor to use it), I thought of splitting it out as a separate patch.
>
> Does this break the sanctity of one self-contained change?
>

This breaks git-bisect, we may want a buildable kernel every commit if possible.

>> > + help
>> > + This will be automatically selected for all processors
>> > + containing this interrupt controller.
>> > + Say N here only if you are really sure.
>> > +

...

>
> Thanks for the review.
>

No problem, dude.
--
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: Wed, Feb 3 2010 7:30 am
From: Eric Miao

On Wed, Feb 3, 2010 at 5:38 AM, Amit Kucheria
<amit.kucheria@canonical.com> wrote:
> On 10 Feb 03, Sascha Hauer wrote:
>> On Tue, Feb 02, 2010 at 10:43:33PM -0800, Eric Miao wrote:
>> >
>> > Mmm.... this should be something that we really need to get rid of, it just
>> > makes a single kernel for both TZIC and AVIC together impossible, if that's
>> > so designed by HW, I'm thinking about keeping this into plat-mxc/ is a good
>> > way to go ...
>> >
>> > Sascha, you have any better idea? Provided the other file debug-macro.S in
>> > the same directory already seems to break the support for multiple arches?
>> >
>>
>> I have the following patch which I'm not sure I like better. It can
>> support both irq controller types and does not add overhead if only one
>> of them is compiled in. It might need some refactoring to fit into Amits
>> patch stack.
>
> Is co-existence of TZIC and AVIC a blocker to merging i.MX5 code? I've
> already made changes so that i.MX5 doesn't explode if AVIC is compiled in.
>
> Admittedly the assembly is a bit hard to rid, but we can fix in another set
> of patches geared towards unification of an i.MX kernel. IMHO, making these
> changes along with introducing a new SoC will make things a bit hard to
> follow/merge.
>

I personally don't feel that's a hard requirement, as long as it can be fixed.
--
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: Unreachable block in Kernel Code (CONFIG_SSB_SDIO)
http://groups.google.com/group/linux.kernel/t/66b3018f2aa264bc?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 7:30 am
From: Christoph Egger

Hi all!

As part of the VAMOS[0] research project at the University of
Erlangen we're checking referential integrity between kernel KConfig
options and in-code Conditional blocks.

In git commit 24ea602e183ca20a7577ebe253323d0e5d0f9847 you
introduced SDIO in drivers/ssb/main.c. While most of the config checks
look for CONFIG_SSB_SDIOHOST there's one check for CONFIG_SSB_SDIO
which looks wrong (and is one of the CONFIG_ vars that are not defined
anywhere in source neither avaiable in kconfig.

Changing this only occurence to SDIOHOST [0] as well however
unfortunately results in a build failure [1] I can't find the correct
way to fix. Maybe you know how to correctly handle that?

Please keep me informed of this patch getting confirmed /
merged so we can keep track of it.

Regards

Christoph Egger

[0]
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -494,7 +494,7 @@ static int ssb_devices_register(struct ssb_bus
*bus)

twitter

Wednesday, February 3, 2010

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

No comments:

Post a Comment