twitter: linux.kernel - 25 new messages in 16 topics

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

Today's topics:

* powerpc: implement arch_scale_smt_power for Power7 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/891f3a14ac88e3fb?hl=en
* rcu: suppress RCU lockdep warnings during early boot - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/793bcd4fc844361a?hl=en
* genericirq: change ack/mask in irq_chip to take irq_desc instead of irq - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/7b1281c0ca4014ea?hl=en
* Add ID and STREAM_ID to recorded event data - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/27a851ce9714f443?hl=en
* [PATCH] Synchronization required before release the lock: sem_post/8-1.c - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/684e0e5d8a32aa0d?hl=en
* x86 platform drivers tree - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/483853d08e1ad890?hl=en
* slab: add memory hotplug support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a8beda1232363b5e?hl=en
* serial: Add OMAP high-speed UART driver. - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/367b898833e91d7d?hl=en
* NOHZ vs. profile/oprofile v2 - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/79bb21849045ad73?hl=en
* memcg: dirty pages instrumentation - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en
* Add firmware for lgs8g75 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/c0089d001f8bd3f7?hl=en
* arch/mips/lib/libgcc.h: Checkpatch cleanup - 4 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e0ce05b42ac96287?hl=en
* kconfig: place git SHA1 in .config output if in git tree - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/9f6a7cb3a5d924c8?hl=en
* Google Gerrit - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/24f53a863abcc323?hl=en
* Firmwares for Sensoray s2255 driver - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/56ae560a8f30db44?hl=en
* sound/oss/v_midi.h: Checkpatch cleanup - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b800dd4f0f5d9f27?hl=en

==============================================================================
TOPIC: powerpc: implement arch_scale_smt_power for Power7
http://groups.google.com/group/linux.kernel/t/891f3a14ac88e3fb?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 6:50 am
From: Peter Zijlstra

On Sat, 2010-02-27 at 21:21 +1100, Michael Neuling wrote:
> In message <11927.1267010024@neuling.org> you wrote:
> > > > If there's less the group will normally be balanced and we fall out and
> > > > end up in check_asym_packing().
> > > >
> > > > So what I tried doing with that loop is detect if there's a hole in the
> > > > packing before busiest. Now that I think about it, what we need to check
> > > > is if this_cpu (the removed cpu argument) is idle and less than busiest.
> > > >
> > > > So something like:
> > > >
> > > > static int check_asym_pacing(struct sched_domain *sd,
> > > > struct sd_lb_stats *sds,
> > > > int this_cpu, unsigned long *imbalance)
> > > > {
> > > > int busiest_cpu;
> > > >
> > > > if (!(sd->flags & SD_ASYM_PACKING))
> > > > return 0;
> > > >
> > > > if (!sds->busiest)
> > > > return 0;
> > > >
> > > > busiest_cpu = group_first_cpu(sds->busiest);
> > > > if (cpu_rq(this_cpu)->nr_running || this_cpu > busiest_cpu)
> > > > return 0;
> > > >
> > > > *imbalance = (sds->max_load * sds->busiest->cpu_power) /
> > > > SCHED_LOAD_SCALE;
> > > > return 1;
> > > > }
> > > >
> > > > Does that make sense?
> > >
> > > I think so.
> > >
> > > I'm seeing check_asym_packing do the right thing with the simple SMT2
> > > with 1 process case. It marks cpu0 as imbalanced when cpu0 is idle and
> > > cpu1 is busy.
> > >
> > > Unfortunately the process doesn't seem to be get migrated down though.
> > > Do we need to give *imbalance a higher value?
> >
> > So with ego help, I traced this down a bit more.
> >
> > In my simple test case (SMT2, t0 idle, t1 active) if f_b_g() hits our
> > new case in check_asym_packing(), load_balance then runs f_b_q().
> > f_b_q() has this:
> >
> > if (capacity && rq->nr_running == 1 && wl > imbalance)
> > continue;
> >
> > when check_asym_packing() hits, wl = 1783 and imbalance = 1024, so we
> > continue and busiest remains NULL.
> >
> > load_balance then does "goto out_balanced" and it doesn't attempt to
> > move the task.
> >
> > Based on this and on egos suggestion I pulled in Suresh Siddha patch
> > from: http://lkml.org/lkml/2010/2/12/352. This fixes the problem. The
> > process is moved down to t0.
> >
> > I've only tested SMT2 so far.
>
> I'm finding this SMT2 result to be unreliable. Sometimes it doesn't work
> for the simple 1 process case. It seems to change boot to boot.
> Sometimes it works as expected with t0 busy and t1 idle, but other times
> it's the other way around.
>
> When it doesn't work, check_asym_packing() is still marking processes to
> be pulled down but only gets run about 1 in every 4 calls to
> load_balance().
>
> For 2 of the other calls to load_balance, idle is CPU_NEWLY_IDLE and
> hence check_asym_packing() doesn't get called. This results in
> sd->nr_balance_failed being reset. When load_balance is next called and
> check_asym_packing() hits, need_active_balance() returns 0 as
> sd->nr_balance_failed is too small. This means the migration thread on
> t1 is not woken and the process remains there.
>
> So why does thread0 change from NEWLY_IDLE to IDLE and visa versa, when
> there is nothing running on it? Is this expected?

Ah, yes, you should probably allow both those.

NEWLY_IDLE is when we are about to schedule the idle thread, IDLE is
when a tick hits the idle thread.

I'm thinking that NEWLY_IDLE should also solve the NO_HZ case, since
we'll have passed through that before we enter tickless state, just make
sure SD_BALANCE_NEWIDLE is set on the relevant levels (should already be
so).

--
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: rcu: suppress RCU lockdep warnings during early boot
http://groups.google.com/group/linux.kernel/t/793bcd4fc844361a?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:00 am
From: "Paul E. McKenney"

On Tue, Mar 02, 2010 at 03:12:57PM +0100, Ingo Molnar wrote:
>
> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>
> > On Tue, Mar 02, 2010 at 01:20:59PM +0100, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > >
> > > > + if (!rcu_scheduler_active || !debug_locks)
> > > > + return 1;
> > > > + return lock_is_held(&rcu_lock_map);
> > >
> > > > + if (!rcu_scheduler_active || !debug_locks)
> > > > + return 1;
> > > > + return lock_is_held(&rcu_bh_lock_map);
> > >
> > > i guess there could be a common helper here?
> >
> > Will do!
> >
> > > Also, could we clear rcu_scheduler_active when we clear debug_locks? That way
> > > only a single test is needed, a generic 'is lock debugging active'.
> >
> > Doing that will break synchronize_rcu(), which returns immediately if
> > !rcu_scheduler_active.
>
> Ok - then have an debug_rcu flag which is cleared appropriately - so that the
> fastpath impact is reduced?

Good point, will do!

Thanx, Paul
--
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: genericirq: change ack/mask in irq_chip to take irq_desc instead of irq
http://groups.google.com/group/linux.kernel/t/7b1281c0ca4014ea?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:00 am
From: Thomas Gleixner

On Wed, 24 Feb 2010, Eric W. Biederman wrote:
> Yinghai Lu <yinghai@kernel.org> writes:
>
> > will have
> > void (*ack)(struct irq_desc *desc);
> > void (*mask)(struct irq_desc *desc);
> > void (*mask_ack)(struct irq_desc *desc);
> > void (*unmask)(struct irq_desc *desc);
> > void (*eoi)(struct irq_desc *desc);
> >
> > so for sparseirq with raidix tree, we don't call extra
> > irq_to_desc, and could use desc directly
>
> Overall this looks pretty decent. This look pretty complete.
> How many platforms did you manage to compile test this on?
>
> I have found a couple of issues (see below).
>
> A few times you change a bit more than is necessary which is a bit
> spooky in a patch this far ranging.
>
> Reading through this patch to review it took an uncomfortably long
> time.

And you didn't even catch all problem spots.

While I like the idea, I really hate the convert wholesale approach.

303 files changed, 3127 insertions(+), 2191 deletions(-)

is fine for a sed script renaming action, but definitely _not_ for
patches which require semantical changes to the affected code.

The right way to do that is

1) add new function pointers, which take irq_desc as their argument

2) make the generic code use them when the old function pointer is
NULL

3) convert the irq_chip implementations one by one with separate
patches

4) Remove the old function pointers and switch the generic code
fully over to use the new ones

Yes, it's more work, but it's less error prone and easier to review,
as the maintainers just have to look at the patch which affects their
particular area.

Thanks,

tglx
--
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 ID and STREAM_ID to recorded event data
http://groups.google.com/group/linux.kernel/t/27a851ce9714f443?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 7:00 am
From: Peter Zijlstra

On Tue, 2010-03-02 at 14:42 +0000, Eric B Munson wrote:
> Currently perf record does not write the ID or the STREAM_ID to disk
> for events. This doesn't allow report to tell if an event stream contains
> one or more types of events. This patch adds these two entries to the list
> of data that record will write to disk.
>
> Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
> ---
> tools/perf/builtin-record.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 771533c..35e4605 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -242,7 +242,8 @@ static void create_counter(int counter, int cpu, pid_t pid)
> PERF_FORMAT_TOTAL_TIME_RUNNING |
> PERF_FORMAT_ID;
>
> - attr->sample_type |= PERF_SAMPLE_IP | PERF_SAMPLE_TID;
> + attr->sample_type |= PERF_SAMPLE_IP | PERF_SAMPLE_TID |
> + PERF_SAMPLE_ID | PERF_SAMPLE_STREAM_ID;
>
> if (freq) {
> attr->sample_type |= PERF_SAMPLE_PERIOD;

can we make this conditional on there being more than one event, that
saves a little space/time when recording

== 2 of 2 ==
Date: Tues, Mar 2 2010 7:20 am
From: Eric B Munson

On Tue, 02 Mar 2010, Peter Zijlstra wrote:

> On Tue, 2010-03-02 at 14:42 +0000, Eric B Munson wrote:
> > Currently perf record does not write the ID or the STREAM_ID to disk
> > for events. This doesn't allow report to tell if an event stream contains
> > one or more types of events. This patch adds these two entries to the list
> > of data that record will write to disk.
> >
> > Signed-off-by: Eric B Munson <ebmunson@us.ibm.com>
> > ---
> > tools/perf/builtin-record.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> > index 771533c..35e4605 100644
> > --- a/tools/perf/builtin-record.c
> > +++ b/tools/perf/builtin-record.c
> > @@ -242,7 +242,8 @@ static void create_counter(int counter, int cpu, pid_t pid)
> > PERF_FORMAT_TOTAL_TIME_RUNNING |
> > PERF_FORMAT_ID;
> >
> > - attr->sample_type |= PERF_SAMPLE_IP | PERF_SAMPLE_TID;
> > + attr->sample_type |= PERF_SAMPLE_IP | PERF_SAMPLE_TID |
> > + PERF_SAMPLE_ID | PERF_SAMPLE_STREAM_ID;
> >
> > if (freq) {
> > attr->sample_type |= PERF_SAMPLE_PERIOD;
>
> can we make this conditional on there being more than one event, that
> saves a little space/time when recording
>

Yeah, I will add that in the next version.

--
Eric B Munson
IBM Linux Technology Center
ebmunson@us.ibm.com

==============================================================================
TOPIC: [PATCH] Synchronization required before release the lock: sem_post/8-1.
c
http://groups.google.com/group/linux.kernel/t/684e0e5d8a32aa0d?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:10 am
From: naresh kamboju

On Tue, Mar 2, 2010 at 2:20 PM, Rishikesh K Rajak
<risrajak@linux.vnet.ibm.com> wrote:
> On Thu, Feb 25, 2010 at 07:15:42PM +0530, naresh kamboju wrote:
>> Hi,
>>
>> I have found abnormal behavior of sem_post/8-1.c test case under posix.
>> This test case passes in some times and failed in many times :-(
>> Patch includes
>> 1. � �Reverting back changes made by mreed on Sep 25 2006. Making sure
>> child has been waiting for the lock (below Refs).
>> 2. � �using sleep in while loop is not a good idea, so sleep is removed
>> from while loop
>> 3. � �For the synchronization I have added sleep before releasing the lock.
>>
>> Signed-off-by: Naresh Kamboju < naresh.kernel@gmail.com >
>
> Looks good to me though i needed few clarification below.
>
> Acked-By: Rishikesh K Rajak <risrajak@linux.vnet.ibm.com>
>
>> ---
>> �testcases/open_posix_testsuite/conformance/interfaces/sem_post/8-1.c
>> | � 15 � �8 + � � 7 - � � 0 !
>> �1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> Index: b/testcases/open_posix_testsuite/conformance/interfaces/sem_post/8-1.c
>> ===================================================================
>> --- a/testcases/open_posix_testsuite/conformance/interfaces/sem_post/8-1.c
>> +++ b/testcases/open_posix_testsuite/conformance/interfaces/sem_post/8-1.c
>> @@ -161,7 +161,6 @@ int main()
>> � � � � }
>> � � � � fprintf(stderr, "P: child_1:%d forked\n", c_1);
>>
>> - � � � sleep(1);
>> � � � � c_2 = fork();
>> � � � � if (c_2 == 0)
>> � � � � {
>> @@ -176,13 +175,13 @@ int main()
>> � � � � }
>> � � � � fprintf(stderr, "P: child_2: %d forked\n", c_2);
>>
>> + � � � �/* Step 3 Implementation */
>> � � � � /* Make sure the two children has been waiting */
>> - � � � /*do {
>> - � � � � � � � sleep(1);
> I feel before getting semaphore value, we need to sync first so here
> sleep is require,though your point is valid that there is no use of
> using sleep inside while loop.
I agree with you.
AFAIU, we should call sleep() before calling getting semaphore
value.when we don't have while loop here. Because while loop condition
is depends on val so when ever we call sem_getvalue() it will get
latest value of val.
In addition to this, we are ensuring val is decremented before we do
unlock the sem by while loop condition.

Having sleep() in while loop will not effect the final output. IIUC

Best regards,
Naresh Kamboju
>> Please review this patch and let me know if you have any issues.
>>
>> Best regards
>> Naresh Kamboju
> --
> Thanks & Regards
> Rishi
> LTP Maintainer
> IBM, LTC, Bangalore
> Please join IRC #ltp @ irc.freenode.net
--
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: x86 platform drivers tree
http://groups.google.com/group/linux.kernel/t/483853d08e1ad890?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 7:10 am
From: Matthew Garrett

Hi Linus,

Here's some misc fixes (including a couple of build fixes), along with
updates to the asus and Thinkpad drivers.

The following changes since commit 30ff056c42c665b9ea535d8515890857ae382540:
Linus Torvalds (1):
Merge branch 'x86-uv-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.git for_linus

Alan Jenkins (2):
eeepc-laptop: disable wireless hotplug for 1005PE
eeepc-laptop: check wireless hotplug events

Corentin Chary (30):
eeepc-laptop: set the right paths in the documentation
asus-laptop: add wireless and bluetooth status parameter
asus-laptop: set the right paths in the documentation
asus-laptop: no need to check argument of set_brightness()
asus-laptop: simplify write_acpi_int
asus-laptop: use tabs to indent macros and remove unused ones
asus-laptop: remove unecessary hotk != NULL check
asus-laptop: change initialization order
asus-laptop: revise names
asus-laptop: move backlight and dsdt info inside asus_laptop struct
asus-laptop: callbacks should use "driver data" parameter or field
asus-laptop: code movement
asus-laptop: stop using read_status for bluetooth and wlan
asus-laptop: stop using read_status and store_status for GPS
asus-laptop: stop using read_status for lcd
asus-laptop: removing read_status/store_status/write_status and asus->status
asus-laptop: rename function talking directly to acpi with asus_xxx scheme
asus-laptop: stop using ASUS_HANDLE and use relative methods instead
asus-laptop: add error check for write_acpi_int calls
asus-laptop: rename wireless_status to wlan_status to avoid confusion
asus-laptop: switch to sparse keymap library
asus-laptop: add bluetooth keys found on M9V
asus-laptop: add backlight changes notifications
asus-laptop: leds, remove dead code and fix asus_led_exit()/asus_led_init()
asus-laptop: set initial lcd state
asus-laptop: add gps rfkill
asus-laptop: clean led code
asus-laptop: use device_create_file() instead of platform_group
asus-laptop: fix style problems reported by checkpath.pl
Merge branch 'eeepc-laptop' into acpi4asus

Frans Pop (1):
toshiba-acpi: fix multimedia keys on some machines

Henrique de Moraes Holschuh (7):
thinkpad-acpi: document HKEY event 3006
thinkpad-acpi: R52 brightness_mode has been confirmed
thinkpad-acpi: fix poll thread auto-start
thinkpad-acpi: make driver events work in NVRAM poll mode
thinkpad-acpi: fix bluetooth/wwan resume
thinkpad-acpi: lock down video output state access
thinkpad-acpi: fix ALSA callback return status

Ingo Molnar (2):
dell-laptop: Fix build error by making buffer_mutex static
compal-laptop: Make it depend on CONFIG_RFKILL

Matthew Garrett (3):
dell-laptop: Fix errors on failure and exit paths
Merge git://git.iksaif.net/acpi4asus into x86-platform
Merge branch 'for-upstream/platform-x86_tpacpi' of git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6 into x86-platform

Roel Kluin (1):
asus-acpi: remove duplicate comparison of asus_model strings

Thadeu Lima de Souza Cascardo (2):
MAINTAINERS: Add git tree to x86 Platform Drivers
classmate-laptop: Added some keys present in other devices

.../ABI/testing/sysfs-platform-asus-laptop | 12 +-
.../ABI/testing/sysfs-platform-eeepc-laptop | 10 +-
Documentation/laptops/thinkpad-acpi.txt | 4 +
MAINTAINERS | 1 +
drivers/platform/x86/Kconfig | 13 +-
drivers/platform/x86/asus-laptop.c | 1741 ++++++++++----------
drivers/platform/x86/asus_acpi.c | 3 +-
drivers/platform/x86/classmate-laptop.c | 4 +
drivers/platform/x86/dell-laptop.c | 9 +-
drivers/platform/x86/eeepc-laptop.c | 21 +-
drivers/platform/x86/thinkpad_acpi.c | 116 +-
drivers/platform/x86/toshiba_acpi.c | 30 +-
12 files changed, 1058 insertions(+), 906 deletions(-)

--
Matthew Garrett | mjg59@srcf.ucam.org
--
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: Tues, Mar 2 2010 7:10 am
From: Matthew Garrett

Hi Linus,

Here's some misc fixes (including a couple of build fixes), along with
updates to the asus and Thinkpad drivers.

The following changes since commit 30ff056c42c665b9ea535d8515890857ae382540:
Linus Torvalds (1):
Merge branch 'x86-uv-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.git for_linus

Alan Jenkins (2):
eeepc-laptop: disable wireless hotplug for 1005PE
eeepc-laptop: check wireless hotplug events

Frans Pop (1):
toshiba-acpi: fix multimedia keys on some machines

Ingo Molnar (2):
dell-laptop: Fix build error by making buffer_mutex static
compal-laptop: Make it depend on CONFIG_RFKILL

Roel Kluin (1):
asus-acpi: remove duplicate comparison of asus_model strings

Thadeu Lima de Souza Cascardo (2):
MAINTAINERS: Add git tree to x86 Platform Drivers
classmate-laptop: Added some keys present in other devices

==============================================================================
TOPIC: slab: add memory hotplug support
http://groups.google.com/group/linux.kernel/t/a8beda1232363b5e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:10 am
From: Pekka Enberg

Hi Andi,

On Tue, Mar 2, 2010 at 2:53 PM, Andi Kleen <andi@firstfloor.org> wrote:
> On Mon, Mar 01, 2010 at 02:24:43AM -0800, David Rientjes wrote:
>> Slab lacks any memory hotplug support for nodes that are hotplugged
>> without cpus being hotplugged. �This is possible at least on x86
>> CONFIG_MEMORY_HOTPLUG_SPARSE kernels where SRAT entries are marked
>> ACPI_SRAT_MEM_HOT_PLUGGABLE and the regions of RAM represent a seperate
>> node. �It can also be done manually by writing the start address to
>> /sys/devices/system/memory/probe for kernels that have
>> CONFIG_ARCH_MEMORY_PROBE set, which is how this patch was tested, and
>> then onlining the new memory region.
>
> The patch looks far more complicated than my simple fix.

I wouldn't exactly call the fallback_alloc() games "simple".

> Is more complicated now better?

Heh, heh. You can't post the oops, you don't want to rework your
patches as per review comments, and now you complain about David's
patch without one bit of technical content. I'm sorry but I must
conclude that someone is playing a prank on me because there's no way
a seasoned kernel hacker such as yourself could possibly think that
this is the way to get patches merged.

But anyway, if you have real technical concerns over the patch, please
make them known; otherwise I'd much appreciate a Tested-by tag from
you for David's patch.

Thanks,

Pekka
--
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: serial: Add OMAP high-speed UART driver.
http://groups.google.com/group/linux.kernel/t/367b898833e91d7d?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 7:10 am
From: "G, Manjunath Kondaiah"

Santosh,

> -----Original Message-----
> From: Shilimkar, Santosh
> Sent: Tuesday, March 02, 2010 7:34 PM
> To: G, Manjunath Kondaiah; S, Venkatraman; Tony Lindgren;
> Raja, Govindraj; Greg KH; linux-serial@vger.kernel.org;
> linux-omap@vger.kernel.org; linux-kernel@vger.kernel.org;
> Kevin Hilman; Olof Johansson
> Subject: RE: [PATCH] serial: Add OMAP high-speed UART driver.
>
> <snip snip>
> > > > --
> > > CDAC is a shadow register used for monitoring the DMA channel.
> > > I think it would be a lot
> > > simpler if omap_start_dma() always resets CDAC to 0, and the
> > > UART driver
> > > just not set it explicitly.
> >
> > This seems to be better option than exposing CDAC read/write API
> > to other drivers since user need to write '0' before
> starting any DMA
> > transfer which can be be done in omap_start_dma().
> >
> > I am wondering how other drivers are using DMA transfer
> API's without
> > resetting CDAC to zero.
> >
> It's needed only if some one is interested in that count.
> UART seems to
> using this counter where as other driver don't.
>
> Why do you think drivers need to know about counter value ?

Reading of non zero value(after reset to zero and enabling dma channel)
from CDAC register indicates that, DMA transfer has started and user can
rely on DMA4_CCENi and DMA4_CCFNi element and frame counters.

If the CDAC value is zero even after starting DMA channel, indicates
error.

-Manjunath

== 2 of 2 ==
Date: Tues, Mar 2 2010 7:20 am
From: "Shilimkar, Santosh"

> -----Original Message-----
> From: G, Manjunath Kondaiah
> Sent: Tuesday, March 02, 2010 8:34 PM
> To: Shilimkar, Santosh; S, Venkatraman; Tony Lindgren; Raja, Govindraj; Greg KH; linux-
> serial@vger.kernel.org; linux-omap@vger.kernel.org; linux-kernel@vger.kernel.org; Kevin Hilman; Olof
> Johansson
> Subject: RE: [PATCH] serial: Add OMAP high-speed UART driver.
>
>
> Santosh,
>
> > -----Original Message-----
> > From: Shilimkar, Santosh
> > Sent: Tuesday, March 02, 2010 7:34 PM
> > To: G, Manjunath Kondaiah; S, Venkatraman; Tony Lindgren;
> > Raja, Govindraj; Greg KH; linux-serial@vger.kernel.org;
> > linux-omap@vger.kernel.org; linux-kernel@vger.kernel.org;
> > Kevin Hilman; Olof Johansson
> > Subject: RE: [PATCH] serial: Add OMAP high-speed UART driver.
> >
> > <snip snip>
> > > > > --
> > > > CDAC is a shadow register used for monitoring the DMA channel.
> > > > I think it would be a lot
> > > > simpler if omap_start_dma() always resets CDAC to 0, and the
> > > > UART driver
> > > > just not set it explicitly.
> > >
> > > This seems to be better option than exposing CDAC read/write API
> > > to other drivers since user need to write '0' before
> > starting any DMA
> > > transfer which can be be done in omap_start_dma().
> > >
> > > I am wondering how other drivers are using DMA transfer
> > API's without
> > > resetting CDAC to zero.
> > >
> > It's needed only if some one is interested in that count.
> > UART seems to
> > using this counter where as other driver don't.
> >
> > Why do you think drivers need to know about counter value ?
>
> Reading of non zero value(after reset to zero and enabling dma channel)
> from CDAC register indicates that, DMA transfer has started and user can
> rely on DMA4_CCENi and DMA4_CCFNi element and frame counters.
>
> If the CDAC value is zero even after starting DMA channel, indicates
> error.
Not necessary. The DMA can still wait for the hw sync signal and the CDAC
can remain 0 if the hw sync in not received. This will be any way returned
by DMA error ( SYNC lost)

This register was mainly suppose to be used for debug purposes.
Regards,
Santosh
--
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: NOHZ vs. profile/oprofile v2
http://groups.google.com/group/linux.kernel/t/79bb21849045ad73?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Mar 2 2010 7:10 am
From: Martin Schwidefsky

On Tue, 02 Mar 2010 15:57:22 +0200
Aaro Koskinen <aaro.koskinen@nokia.com> wrote:

> Hi,
>
> Martin Schwidefsky wrote:
> > First version of the hrtimer patch for oprofile. I did not add the
> > sysctl yet, if the sysctl is added in oprofile_timer_init it would not
> > be available if some better profiling source is available. If it is
> > added unconditionally it would only have an effect if the timer
> > fallback is used. Both cases are not exactly nice for a user space
> > interface.
>
> I wonder what happened to this patch? Some platforms would need
> this fix (i.e. the timer mode has to be used due to HW issues).

After SH removed their oprofile hook there is nothing left that would
prevent us from converting oprofile to hrtimer. Just a matter of
reminding me and have me try again ;-)

Patch against current git. Ingo, Thomas: one for the timer tree I guess.

--
Subject: [PATCH] convert oprofile from timer_hook to hrtimer

From: Martin Schwidefsky <schwidefsky@de.ibm.com>

Oprofile is currently broken on systems running with NOHZ enabled.
A maximum of 1 tick is accounted via the timer_hook if a cpu sleeps
for a longer period of time. This does bad things to the percentages
in the profiler output. To solve this problem convert oprofile to
use a restarting hrtimer instead of the timer_hook.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---

drivers/oprofile/oprof.c | 12 ++++--
drivers/oprofile/oprof.h | 3 +
drivers/oprofile/timer_int.c | 78 ++++++++++++++++++++++++++++++++++++++-----
3 files changed, 79 insertions(+), 14 deletions(-)

diff -urpN linux-2.6/drivers/oprofile/oprof.c linux-2.6-patched/drivers/oprofile/oprof.c
--- linux-2.6/drivers/oprofile/oprof.c 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6-patched/drivers/oprofile/oprof.c 2010-03-02 15:57:02.000000000 +0100
@@ -253,22 +253,26 @@ static int __init oprofile_init(void)
int err;

err = oprofile_arch_init(&oprofile_ops);
-
if (err < 0 || timer) {
printk(KERN_INFO "oprofile: using timer interrupt.\n");
- oprofile_timer_init(&oprofile_ops);
+ err = oprofile_timer_init(&oprofile_ops);
+ if (err)
+ goto out_arch;
}
-
err = oprofilefs_register();
if (err)
- oprofile_arch_exit();
+ goto out_arch;
+ return 0;

+out_arch:
+ oprofile_arch_exit();
return err;
}

static void __exit oprofile_exit(void)
{
+ oprofile_timer_exit();
oprofilefs_unregister();
oprofile_arch_exit();
}
diff -urpN linux-2.6/drivers/oprofile/oprof.h linux-2.6-patched/drivers/oprofile/oprof.h
--- linux-2.6/drivers/oprofile/oprof.h 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6-patched/drivers/oprofile/oprof.h 2010-03-02 15:57:02.000000000 +0100
@@ -34,7 +34,8 @@ struct super_block;
struct dentry;

void oprofile_create_files(struct super_block *sb, struct dentry *root);
-void oprofile_timer_init(struct oprofile_operations *ops);
+int oprofile_timer_init(struct oprofile_operations *ops);
+void oprofile_timer_exit(void);

int oprofile_set_backtrace(unsigned long depth);
int oprofile_set_timeout(unsigned long time);
diff -urpN linux-2.6/drivers/oprofile/timer_int.c linux-2.6-patched/drivers/oprofile/timer_int.c
--- linux-2.6/drivers/oprofile/timer_int.c 2010-02-24 19:52:17.000000000 +0100
+++ linux-2.6-patched/drivers/oprofile/timer_int.c 2010-03-02 15:57:02.000000000 +0100
@@ -13,34 +13,94 @@
#include <linux/oprofile.h>
#include <linux/profile.h>
#include <linux/init.h>
+#include <linux/cpu.h>
+#include <linux/hrtimer.h>
+#include <asm/irq_regs.h>
#include <asm/ptrace.h>

#include "oprof.h"

-static int timer_notify(struct pt_regs *regs)
+static DEFINE_PER_CPU(struct hrtimer, oprofile_hrtimer);
+
+static enum hrtimer_restart oprofile_hrtimer_notify(struct hrtimer *hrtimer)
+{
+ oprofile_add_sample(get_irq_regs(), 0);
+ hrtimer_forward_now(hrtimer, ns_to_ktime(TICK_NSEC));
+ return HRTIMER_RESTART;
+}
+
+static void __oprofile_hrtimer_start(void *unused)
+{
+ struct hrtimer *hrtimer = &__get_cpu_var(oprofile_hrtimer);
+
+ hrtimer_init(hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ hrtimer->function = oprofile_hrtimer_notify;
+
+ hrtimer_start(hrtimer, ns_to_ktime(TICK_NSEC),
+ HRTIMER_MODE_REL_PINNED);
+}
+
+static int oprofile_hrtimer_start(void)
{
- oprofile_add_sample(regs, 0);
+ on_each_cpu(__oprofile_hrtimer_start, NULL, 1);
return 0;
}

-static int timer_start(void)
+static void __oprofile_hrtimer_stop(int cpu)
{
- return register_timer_hook(timer_notify);
+ struct hrtimer *hrtimer = &per_cpu(oprofile_hrtimer, cpu);
+
+ hrtimer_cancel(hrtimer);
}

+static void oprofile_hrtimer_stop(void)
+{
+ int cpu;
+
+ for_each_online_cpu(cpu)
+ __oprofile_hrtimer_stop(cpu);
+}

-static void timer_stop(void)
+static int __cpuinit oprofile_cpu_notify(struct notifier_block *self,
+ unsigned long action, void *hcpu)
{
- unregister_timer_hook(timer_notify);
+ long cpu = (long) hcpu;
+
+ switch (action) {
+ case CPU_ONLINE:
+ case CPU_ONLINE_FROZEN:
+ smp_call_function_single(cpu, __oprofile_hrtimer_start,
+ NULL, 1);
+ break;
+ case CPU_DEAD:
+ case CPU_DEAD_FROZEN:
+ __oprofile_hrtimer_stop(cpu);
+ break;
+ }
+ return NOTIFY_OK;
}

+static struct notifier_block __refdata oprofile_cpu_notifier = {
+ .notifier_call = oprofile_cpu_notify,
+};

-void __init oprofile_timer_init(struct oprofile_operations *ops)
+int __init oprofile_timer_init(struct oprofile_operations *ops)
{
+ int rc;
+
+ rc = register_hotcpu_notifier(&oprofile_cpu_notifier);
+ if (rc)
+ return rc;
ops->create_files = NULL;
ops->setup = NULL;
ops->shutdown = NULL;
- ops->start = timer_start;
- ops->stop = timer_stop;
+ ops->start = oprofile_hrtimer_start;
+ ops->stop = oprofile_hrtimer_stop;
ops->cpu_type = "timer";
+ return 0;
+}
+
+void __exit oprofile_timer_exit(void)
+{
+ unregister_hotcpu_notifier(&oprofile_cpu_notifier);
}

--
blue skies,
Martin.

"Reality continues to ruin my life." - Calvin.

== 2 of 3 ==
Date: Tues, Mar 2 2010 7:10 am
From: Thomas Gleixner

On Tue, 2 Mar 2010, Martin Schwidefsky wrote:

> On Tue, 02 Mar 2010 15:57:22 +0200
> Aaro Koskinen <aaro.koskinen@nokia.com> wrote:
>
> > Hi,
> >
> > Martin Schwidefsky wrote:
> > > First version of the hrtimer patch for oprofile. I did not add the
> > > sysctl yet, if the sysctl is added in oprofile_timer_init it would not
> > > be available if some better profiling source is available. If it is
> > > added unconditionally it would only have an effect if the timer
> > > fallback is used. Both cases are not exactly nice for a user space
> > > interface.
> >
> > I wonder what happened to this patch? Some platforms would need
> > this fix (i.e. the timer mode has to be used due to HW issues).
>
> After SH removed their oprofile hook there is nothing left that would
> prevent us from converting oprofile to hrtimer. Just a matter of
> reminding me and have me try again ;-)
>
> Patch against current git. Ingo, Thomas: one for the timer tree I guess.

No objections from my side, but shouldn't that go via Robert ?

Thanks,

tglx

> --
> Subject: [PATCH] convert oprofile from timer_hook to hrtimer
>
> From: Martin Schwidefsky <schwidefsky@de.ibm.com>
>
> Oprofile is currently broken on systems running with NOHZ enabled.
> A maximum of 1 tick is accounted via the timer_hook if a cpu sleeps
> for a longer period of time. This does bad things to the percentages
> in the profiler output. To solve this problem convert oprofile to
> use a restarting hrtimer instead of the timer_hook.
>
> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
> ---
>
> drivers/oprofile/oprof.c | 12 ++++--
> drivers/oprofile/oprof.h | 3 +
> drivers/oprofile/timer_int.c | 78 ++++++++++++++++++++++++++++++++++++++-----
> 3 files changed, 79 insertions(+), 14 deletions(-)
>
> diff -urpN linux-2.6/drivers/oprofile/oprof.c linux-2.6-patched/drivers/oprofile/oprof.c
> --- linux-2.6/drivers/oprofile/oprof.c 2010-02-24 19:52:17.000000000 +0100
> +++ linux-2.6-patched/drivers/oprofile/oprof.c 2010-03-02 15:57:02.000000000 +0100
> @@ -253,22 +253,26 @@ static int __init oprofile_init(void)
> int err;
>
> err = oprofile_arch_init(&oprofile_ops);
> -
> if (err < 0 || timer) {
> printk(KERN_INFO "oprofile: using timer interrupt.\n");
> - oprofile_timer_init(&oprofile_ops);
> + err = oprofile_timer_init(&oprofile_ops);
> + if (err)
> + goto out_arch;
> }
> -
> err = oprofilefs_register();
> if (err)
> - oprofile_arch_exit();
> + goto out_arch;
> + return 0;
>
> +out_arch:
> + oprofile_arch_exit();
> return err;
> }
>
>
> static void __exit oprofile_exit(void)
> {
> + oprofile_timer_exit();
> oprofilefs_unregister();
> oprofile_arch_exit();
> }
> diff -urpN linux-2.6/drivers/oprofile/oprof.h linux-2.6-patched/drivers/oprofile/oprof.h
> --- linux-2.6/drivers/oprofile/oprof.h 2010-02-24 19:52:17.000000000 +0100
> +++ linux-2.6-patched/drivers/oprofile/oprof.h 2010-03-02 15:57:02.000000000 +0100
> @@ -34,7 +34,8 @@ struct super_block;
> struct dentry;
>
> void oprofile_create_files(struct super_block *sb, struct dentry *root);
> -void oprofile_timer_init(struct oprofile_operations *ops);
> +int oprofile_timer_init(struct oprofile_operations *ops);
> +void oprofile_timer_exit(void);
>
> int oprofile_set_backtrace(unsigned long depth);
> int oprofile_set_timeout(unsigned long time);
> diff -urpN linux-2.6/drivers/oprofile/timer_int.c linux-2.6-patched/drivers/oprofile/timer_int.c
> --- linux-2.6/drivers/oprofile/timer_int.c 2010-02-24 19:52:17.000000000 +0100
> +++ linux-2.6-patched/drivers/oprofile/timer_int.c 2010-03-02 15:57:02.000000000 +0100
> @@ -13,34 +13,94 @@
> #include <linux/oprofile.h>
> #include <linux/profile.h>
> #include <linux/init.h>
> +#include <linux/cpu.h>
> +#include <linux/hrtimer.h>
> +#include <asm/irq_regs.h>
> #include <asm/ptrace.h>
>
> #include "oprof.h"
>
> -static int timer_notify(struct pt_regs *regs)
> +static DEFINE_PER_CPU(struct hrtimer, oprofile_hrtimer);
> +
> +static enum hrtimer_restart oprofile_hrtimer_notify(struct hrtimer *hrtimer)
> +{
> + oprofile_add_sample(get_irq_regs(), 0);
> + hrtimer_forward_now(hrtimer, ns_to_ktime(TICK_NSEC));
> + return HRTIMER_RESTART;
> +}
> +
> +static void __oprofile_hrtimer_start(void *unused)
> +{
> + struct hrtimer *hrtimer = &__get_cpu_var(oprofile_hrtimer);
> +
> + hrtimer_init(hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + hrtimer->function = oprofile_hrtimer_notify;
> +
> + hrtimer_start(hrtimer, ns_to_ktime(TICK_NSEC),
> + HRTIMER_MODE_REL_PINNED);
> +}
> +
> +static int oprofile_hrtimer_start(void)
> {
> - oprofile_add_sample(regs, 0);
> + on_each_cpu(__oprofile_hrtimer_start, NULL, 1);
> return 0;
> }
>
> -static int timer_start(void)
> +static void __oprofile_hrtimer_stop(int cpu)
> {
> - return register_timer_hook(timer_notify);
> + struct hrtimer *hrtimer = &per_cpu(oprofile_hrtimer, cpu);
> +
> + hrtimer_cancel(hrtimer);
> }
>
> +static void oprofile_hrtimer_stop(void)
> +{
> + int cpu;
> +
> + for_each_online_cpu(cpu)
> + __oprofile_hrtimer_stop(cpu);
> +}
>
> -static void timer_stop(void)
> +static int __cpuinit oprofile_cpu_notify(struct notifier_block *self,
> + unsigned long action, void *hcpu)
> {
> - unregister_timer_hook(timer_notify);
> + long cpu = (long) hcpu;
> +
> + switch (action) {
> + case CPU_ONLINE:
> + case CPU_ONLINE_FROZEN:
> + smp_call_function_single(cpu, __oprofile_hrtimer_start,
> + NULL, 1);
> + break;
> + case CPU_DEAD:
> + case CPU_DEAD_FROZEN:
> + __oprofile_hrtimer_stop(cpu);
> + break;
> + }
> + return NOTIFY_OK;
> }
>
> +static struct notifier_block __refdata oprofile_cpu_notifier = {
> + .notifier_call = oprofile_cpu_notify,
> +};
>
> -void __init oprofile_timer_init(struct oprofile_operations *ops)
> +int __init oprofile_timer_init(struct oprofile_operations *ops)
> {
> + int rc;
> +
> + rc = register_hotcpu_notifier(&oprofile_cpu_notifier);
> + if (rc)
> + return rc;
> ops->create_files = NULL;
> ops->setup = NULL;
> ops->shutdown = NULL;
> - ops->start = timer_start;
> - ops->stop = timer_stop;
> + ops->start = oprofile_hrtimer_start;
> + ops->stop = oprofile_hrtimer_stop;
> ops->cpu_type = "timer";
> + return 0;
> +}
> +
> +void __exit oprofile_timer_exit(void)
> +{
> + unregister_hotcpu_notifier(&oprofile_cpu_notifier);
> }
>
> --
> blue skies,
> Martin.
>
> "Reality continues to ruin my life." - Calvin.
>
--
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/

== 3 of 3 ==
Date: Tues, Mar 2 2010 7:30 am
From: Martin Schwidefsky

On Tue, 2 Mar 2010 16:08:09 +0100 (CET)
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Tue, 2 Mar 2010, Martin Schwidefsky wrote:
>
> > On Tue, 02 Mar 2010 15:57:22 +0200
> > Aaro Koskinen <aaro.koskinen@nokia.com> wrote:
> >
> > > Hi,
> > >
> > > Martin Schwidefsky wrote:
> > > > First version of the hrtimer patch for oprofile. I did not add the
> > > > sysctl yet, if the sysctl is added in oprofile_timer_init it would not
> > > > be available if some better profiling source is available. If it is
> > > > added unconditionally it would only have an effect if the timer
> > > > fallback is used. Both cases are not exactly nice for a user space
> > > > interface.
> > >
> > > I wonder what happened to this patch? Some platforms would need
> > > this fix (i.e. the timer mode has to be used due to HW issues).
> >
> > After SH removed their oprofile hook there is nothing left that would
> > prevent us from converting oprofile to hrtimer. Just a matter of
> > reminding me and have me try again ;-)
> >
> > Patch against current git. Ingo, Thomas: one for the timer tree I guess.
>
> No objections from my side, but shouldn't that go via Robert ?

Agreed, this should be handled by the oprofile maintainer.
Robert, could you take care of the patch?

--
blue skies,
Martin.

"Reality continues to ruin my life." - Calvin.

==============================================================================
TOPIC: memcg: dirty pages instrumentation
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 7:10 am
From: Vivek Goyal

On Mon, Mar 01, 2010 at 11:18:31PM +0100, Andrea Righi wrote:
> On Mon, Mar 01, 2010 at 05:02:08PM -0500, Vivek Goyal wrote:
> > > @@ -686,10 +699,14 @@ void throttle_vm_writeout(gfp_t gfp_mask)
> > > */
> > > dirty_thresh += dirty_thresh / 10; /* wheeee... */
> > >
> > > - if (global_page_state(NR_UNSTABLE_NFS) +
> > > - global_page_state(NR_WRITEBACK) <= dirty_thresh)
> > > - break;
> > > - congestion_wait(BLK_RW_ASYNC, HZ/10);
> > > +
> > > + dirty = mem_cgroup_page_stat(MEMCG_NR_DIRTY_WRITEBACK_PAGES);
> > > + if (dirty < 0)
> > > + dirty = global_page_state(NR_UNSTABLE_NFS) +
> > > + global_page_state(NR_WRITEBACK);
> >
> > dirty is unsigned long. As mentioned last time, above will never be true?
> > In general these patches look ok to me. I will do some testing with these.
>
> Re-introduced the same bug. My bad. :(
>
> The value returned from mem_cgroup_page_stat() can be negative, i.e.
> when memory cgroup is disabled. We could simply use a long for dirty,
> the unit is in # of pages so s64 should be enough. Or cast dirty to long
> only for the check (see below).
>
> Thanks!
> -Andrea
>
> Signed-off-by: Andrea Righi <arighi@develer.com>
> ---
> mm/page-writeback.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index d83f41c..dbee976 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -701,7 +701,7 @@ void throttle_vm_writeout(gfp_t gfp_mask)
>
>
> dirty = mem_cgroup_page_stat(MEMCG_NR_DIRTY_WRITEBACK_PAGES);
> - if (dirty < 0)
> + if ((long)dirty < 0)

This will also be problematic as on 32bit systems, your uppper limit of
dirty memory will be 2G?

I guess, I will prefer one of the two.

- return the error code from function and pass a pointer to store stats
in as function argument.

- Or Peter's suggestion of checking mem_cgroup_has_dirty_limit() and if
per cgroup dirty control is enabled, then use per cgroup stats. In that
case you don't have to return negative values.

Only tricky part will be careful accouting so that none of the stats go
negative in corner cases of migration etc.

Thanks
Vivek

> dirty = global_page_state(NR_UNSTABLE_NFS) +
> global_page_state(NR_WRITEBACK);
> if (dirty <= dirty_thresh)
--
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: Tues, Mar 2 2010 7:30 am
From: Balbir Singh

* Peter Zijlstra <peterz@infradead.org> [2010-03-02 14:48:56]:

> This is ugly and broken.. I thought you'd agreed to something like:
>
> if (mem_cgroup_has_dirty_limit(cgroup))
> use mem_cgroup numbers
> else
> use global numbers
>
> That allows for a 0 dirty limit (which should work and basically makes
> all io synchronous).
>
> Also, I'd put each of those in a separate function, like:
>
> unsigned long reclaimable_pages(cgroup)
> {
> if (mem_cgroup_has_dirty_limit(cgroup))
> return mem_cgroup_page_stat(MEMCG_NR_RECLAIM_PAGES);
>
> return global_page_state(NR_FILE_DIRTY) + global_page_state(NR_NFS_UNSTABLE);
> }
>

I agree, I should have been more specific about the naming convention,
this is what I meant - along these lines as we do with
zone_nr_lru_pages(), etc.

> Which raises another question, you should probably rebase on top of
> Trond's patches, which removes BDI_RECLAIMABLE, suggesting you also
> loose MEMCG_NR_RECLAIM_PAGES in favour of the DIRTY+UNSTABLE split.
>

--
Three Cheers,
Balbir
--
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 firmware for lgs8g75
http://groups.google.com/group/linux.kernel/t/c0089d001f8bd3f7?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:10 am
From: Mauro Carvalho Chehab

Ben Hutchings wrote:
> This is taken from the lgs8gxx driver as of 2.6.32-rc5.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> The binary changes are omitted from this message as they are impossible
> to review.

Hi Ben,

This patch can't be applied, as the firmware is missing on it.

Cheers,
Mauro.
>
> Ben.
>
> WHENCE | 9 +++++++++
> lgs8g75.fw | Bin 0 -> 262 bytes
> 2 files changed, 9 insertions(+), 0 deletions(-)
> create mode 100644 lgs8g75.fw
>
> diff --git a/WHENCE b/WHENCE
> index d62468e..659e255 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -1184,3 +1184,12 @@ Found in hex form in kernel source.
>
> --------------------------------------------------------------------------
>
> +Driver: lgs8gxx - Legend Silicon GB20600 demodulator driver
> +
> +File: lgs8g75.fw
> +
> +Licence: Unknown
> +
> +Found in hex form in kernel source.
> +
> +--------------------------------------------------------------------------
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

Cheers,
Mauro
--
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: arch/mips/lib/libgcc.h: Checkpatch cleanup
http://groups.google.com/group/linux.kernel/t/e0ce05b42ac96287?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Mar 2 2010 7:20 am
From: Andrea Gelmini

2010/3/1 Paul Mundt <lethal@linux-sh.org>:
Hi Paul,
thanks for your reply.

> I'll apply the sh part by itself, and I suppose Ralf will do the same for
> MIPS. I'm a bit confused as to why these were lumped together when 65 out
> of 66 oneliner patches made no use of ad-hoc grouping.

After the experience with GregKH, I was looking for others maintainer
interested in code cleanup. So I sent some patches over random files.
If you care, I can checkpatch.pl all mips subtree and send you patches (if any).

Thanks a lot for your work,
Andrea
--
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: Tues, Mar 2 2010 7:20 am
From: Andrea Gelmini

2010/2/28 Jeff Dike <jdike@addtoit.com>:
Hi Jeff,
and thanks for your reply.

> checkpatch violations. I cleaned up a lot of it while making other
> changes in the area. This sort of thing I think is reasonably
> worthwhile, but dumping in a whole lot of checkpatch changes doesn't
> help anything and it just pollutes the change history.

Yep, I talked about side effects (i.e git-blame) with Alessandro (Rubini).
If you think it could be useuful I can check all the subtree. Send
you patches (if any).
You can merge piece of them as soon as you modify files with real
patches, so you
don't have to do the boring business. I don't care to have credits
about 'em, and it's not
a problem if you will not use them.

Thanks a lot,
Andrea
--
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/

== 3 of 4 ==
Date: Tues, Mar 2 2010 7:30 am
From: Andrea Gelmini

2010/2/28 Al Viro <viro@zeniv.linux.org.uk>:
Hi Viro,
thanks a lot for your reply.

> Note to gregkh: the next time you give a talk like that, consider including
> "spamming l-k with sixty-odd solitaire sessions^W^Wwhitespace-removal patches
> can lead to considerable annoyance"...

As you can see in the video, Greg talked about - just and only -
Staging Drivers.

It's all my fault if someone is bored with my patches.

== 4 of 4 ==
Date: Tues, Mar 2 2010 7:30 am
From: Andrea Gelmini

2010/3/2 Marcelo Tosatti <mtosatti@redhat.com>:
Hi Marcelo,
thanks a lot for your reply.

> Applied, thanks.

Thanks a lot.
If you care I can check all the KVM files.

Thanks again,
Andrea
--
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: kconfig: place git SHA1 in .config output if in git tree
http://groups.google.com/group/linux.kernel/t/9f6a7cb3a5d924c8?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:20 am
From: Frans Pop

On Tuesday 02 March 2010, Paul E. McKenney wrote:
> Sigh! Because popen() doesn't fail when the command is bogus, it seems.
> I now do stat() to check for it existing, and that seems to handle the
> remote-output case.

Cool. Did you check if it's really necessary to treat the two cases
separately? I would expect srctree to always be set, and if I read the
root Makefile correctly that's indeed the case:
srctree := $(if $(KBUILD_SRC),$(KBUILD_SRC),$(CURDIR))

Hmm. I see you've switched from SRCTREE to KBUILD_SRC. Is that correct?
SCRTREE is also used elsewhere in the same file and that's the variable
(in lower case; the upper case variant is a C define) that's explicitly
exported in the root Makefile.

> > One other thing. I wonder if this implementation will always reliably
> > result in the *current* SHA1 being included in the .config. AFAICT
> > the .config only actually gets written if there are changes, or if you
> > explicitly do a 'make oldconfig'.
> >
> > But if you e.g. pull a stable update and just run 'make', the .config
> > will likely remain unchanged and will thus still contain the SHA1 from
> > a previous build.
>
> Good point. But the same is true of the Linux kernel version
> identifier, right?

Right. But the increased precision of the SHA1 IMO also demands an
increased reliability of its accuracy: if it's not accurate it loses its
value.

Personally I think that maybe the config file is not the correct place for
this. For one thing users may well send a config file that's not the 100%
exact one used to build the kernel when they know it's close enough that
it makes no practical difference (I know I've done so in the past).

Wouldn't it be more logical to include the line in the dmesg output? My
preference would be a separate line below the existing (Linux version)
line. That line could only be output if the kernel was built from a VCS.
It could then even be repeated in oops output.

That would also solve the problem of the config file not being updated.

Paul E. McKenney wrote:
>> I'd hate to have that run every time I make a kernel.
>
> Good point... Should we have an environment variable that controls this
> behavior?

I would suggest at most a general enabled/disabled switch (distros might
prefer to disable it too), and not more detailed settings to control
whether or not to include dirty or whatnot.

Cheers,
FJP
--
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: Google Gerrit
http://groups.google.com/group/linux.kernel/t/24f53a863abcc323?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:30 am
From: "Shawn O. Pearce"

Anca Emanuel <anca.emanuel@gmail.com> wrote:
> Hi, what do you think about Google Gerrit ? http://code.google.com/p/gerrit/
>
> see it in action here: http://review.source.android.com

For kernel or at least C-ish folk... a kernel patch under development
might be more relevant to point to. E.g.:

https://review.source.android.com/13610

> quote:
> "Gerrit is a web based code review system, facilitating online code
> reviews for projects using the Git version control system.
> Gerrit makes reviews easier by showing changes in a side-by-side
> display, and allowing inline comments to be added by any reviewer.
> Gerrit simplifies Git based project maintainership by permitting any
> authorized user to submit changes to the master Git repository, rather
> than requiring all approved changes to be merged in by hand by the
> project maintainer. This functionality enables a more centralized
> usage of Git."

I hate that description. I keep meaning to overhaul the project
landing page with screenshots and try to describe the feature set
better, but I've been too busy with coding.

> git needs an friendly UI, web based is the future.

We have a number of UIs for Git... some more user friendly to
certain classes of users than others. But I'm not sold that a
web based interface is the future.

Sometimes a web UI can be very convient to work with. Sometimes, the
existing mailing list review infrastructure works very well. What I
love most about Git is how much choice we really have as users.

> Maybe an integration with Wave.

Maybe. But I'm not actively pursuing that right now. If someone
else develops a Gitty bot for Wave, that would be cool.

Actually... my goal over the next couple of months here is to
make Gerrit Code Review no longer dependent on a web UI, or on a
backend SQL database. I'm going to shift all of the data storage
into Git meta branches, and the code annotations into Git notes.
Which will make it very friendly to build other tools like an Emacs
plugin that can interoperate based solely on raw Git commands and
formats, without ever touching the existing Java or web UI.

I think the biggest challenge I have is I need a good inverted
search index, and Git has no standard for that. I'm tempted to
use Apache Lucene[1] because in Java its simple to work with,
but their C port has been dangling in the wind for a long time.

[1] http://lucene.apache.org/

--
Shawn.
--
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: Firmwares for Sensoray s2255 driver
http://groups.google.com/group/linux.kernel/t/56ae560a8f30db44?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:30 am
From: Mauro Carvalho Chehab

The following changes since commit c024a251e1dd1a39de610bbdc2af65b36e42637d:
David Woodhouse (1):
Merge from fixed from-kernel tree to fix Matrox firmware binaries

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git master

Mauro Carvalho Chehab (2):
Firmware for Sensoray s2255 webcam drivers
Additional firmwares for Sensoray s2255 webcam drivers

WHENCE | 14 ++++++++++++++
f2255usb.bin | Bin 0 -> 180760 bytes
s2250.fw | Bin 0 -> 9508 bytes
s2250_loader.fw | Bin 0 -> 1092 bytes
4 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 f2255usb.bin
create mode 100644 s2250.fw
create mode 100644 s2250_loader.fw
--
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: sound/oss/v_midi.h: Checkpatch cleanup
http://groups.google.com/group/linux.kernel/t/b800dd4f0f5d9f27?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:30 am
From: Andrea Gelmini

2010/3/2 Takashi Iwai <tiwai@suse.de>:
Hi Takashi,
thanks a lot for you reply.

> Applied all three patches for sound/* now. Thanks.

Thanks a lot.
If you care I can check all sound subtree.

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

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

Tuesday, March 2, 2010

linux.kernel - 25 new messages in 16 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts