>> static unsigned long weighted_cpuload(const int cpu)
>> {
>> -return cpu_rq(cpu)->load.weight;
>> +return (unsigned long)cpu_rq(cpu)->cfs.runnable_load_avg;
>
> Above line change cause aim9 multitask benchmark drop about 10%
> performance on many x86 machines. Profile just show
On Sun, 2013-01-06 at 03:52 +0100, Willy Tarreau wrote:
> OK so I observed no change with this patch, either on the loopback
> data rate at >16kB MTU, or on the myri. I'm keeping it at hand for
> experimentation anyway.
>
Yeah, there was no bug. I rewrote it for net-next as a cleanup/optim
This is an update version of last version to fix the handling of polling errors
in vhost/vhost_net.
Currently, vhost and vhost_net ignore polling errors which can lead kernel
crashing when it tries to remove itself from waitqueue after the polling
failure. Fix this by checking the poll->wqh
Polling errors were ignored by vhost/vhost_net, this may lead to crash when
trying to remove vhost from waitqueue when after the polling is failed. Solve
this problem by:
- checking the poll->wqh before trying to remove from waitqueue
- report an error when poll() returns a POLLERR in
Currently, when vhost_init_used() fails the sock refcnt and ubufs were
leaked. Correct this by calling vhost_init_used() before assign ubufs and
restore the oldsock when it fails.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c | 16 +++-
1 files changed, 11 insertions(+), 5
when run the folloing command under shell, it will return error
sh/$ echo 1 > /proc/sys/vm/compact_memory
sh/$ sh: write error: Bad address
After strace, I found the following log:
...
write(1, "1\n", 2) = 3
write(1, "", 4294967295) = -1 EFAULT (Bad address)
write(2, "echo:
On Fri, Jan 04, 2013 at 09:16:08PM +0200, Pantelis Antoniou wrote:
> After fixing the is_printable bug the test suite fails.
> Fix it with this patch
>
> Signed-off-by: Pantelis Antoniou
Rather than just removing the test, it would be better to still run it
using an explicit -t bi to force the
> Why dont use enums for this?
enums can have unpredictable signed/unsignedness issues. #defines for
hardware constants is usually far safer.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
The tricky problem is this check:
if (i++ >= max)
icc (mis)optimizes this check as:
if (++i > max)
The check now becomes a no-op since max is MAX_ARG_STRINGS (0x7FFF).
This is "allowed" by the C standard, assuming i++ never overflows,
because signed integer overflow is
On Sat, Dec 08, 2012 at 06:16:35PM +0100, Julia Lawall wrote:
> From: Julia Lawall
>
> devm_request_threaded_irq requests and irq that is freed when a driver
> detaches. This patch uses devm_request_threaded_irq for irqs that are
> requested in the probe function of a platform device and are
On 01/06/2013 03:37 AM, Eric Dumazet wrote:
> On Sat, 2013-01-05 at 17:34 +0800, Jason Wang wrote:
>> Currently, tun_chr_poll() returns POLLERR after waitqueue adding during
>> device
>> unregistration. This would confuse some of its user such as vhost which
>> assume
>> when POLLERR is
Signed-off-by: Axel Lin
---
drivers/regulator/da9055-regulator.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/regulator/da9055-regulator.c
b/drivers/regulator/da9055-regulator.c
index 1a05ac6..3022109 100644
--- a/drivers/regulator/da9055-regulator.c
+++
On 01/05/2013 03:35:58 AM, Richard Cochran wrote:
On Sat, Jan 05, 2013 at 12:16:51AM -0600, Joel A Fernandes wrote:
>
> The problem being addressed is discussed in this thread:
> http://permalink.gmane.org/gmane.linux.kernel/1389017
Thanks for the link.
Since the motivation is already
Adding more people in case somebody else has any idea. Anybody?
On Sat, Jan 5, 2013 at 7:22 AM, Dave Jones wrote:
> I have no idea what happened here, but this is the first time I've seen this
> one.
> This was running a tree pulled yesterday afternoon.
>
> BUG: unable to handle kernel paging
- Original Message -
> From: "Oleg Nesterov"
> To: "CAI Qian" , "Andrew Morton"
> , "Linus Torvalds"
>
> Cc: "Linda Wang" , "Matt Zywusko" ,
> "Al Viro" ,
> linux-kernel@vger.kernel.org
> Sent: Sunday, January 6, 2013 2:13:13 AM
> Subject: [PATCH 1/2] signals: sys_ssetmask() uses
On Fri, Dec 07, 2012 at 05:23:28PM +0530, Sachin Kamat wrote:
> devm_regulator_get() is device managed and makes error handling
> and code cleanup simpler.
>
> Cc: Arun R Murthy
> Signed-off-by: Sachin Kamat
> ---
> Compile tested using linux-next.
> ---
Applied, thanks!
>
On Sun, Dec 02, 2012 at 08:34:21PM +1100, NeilBrown wrote:
> commit a66f59ba2e994bf70274ef0513e24e0e7ae20c63
> bq27x00_battery: Add support for BQ27425 chip
>
> introduced 2 bug.
>
> 1/ 'chip' was set to BQ27425 unconditionally - breaking support for
>other devices.
> 2/ BQ27425 does not
On Fri, Nov 30, 2012 at 01:57:46PM +0530, Ramakrishna Pallala wrote:
> As most of the charger chips come with two kinds of safety features
> related to timing.
> 1. Watchdog Timer (interms of seconds/mins)
> 2. Safety Timer (interms of hours)
>
> This patch adds these to fault causes in
On Fri, Dec 28, 2012 at 9:10 AM, Kamezawa Hiroyuki
wrote:
> (2012/12/26 2:28), Sha Zhengju wrote:
>> From: Sha Zhengju
>>
>> Signed-off-by: Sha Zhengju
>
> I don't think your words are bad but it may be better to sync with meminfo's
> text.
>
>> ---
>> Documentation/cgroups/memory.txt |2
On Tue, Nov 27, 2012 at 01:17:02PM +0530, Ramakrishna Pallala wrote:
[...]
> +++ b/drivers/power/power_supply_core.c
> @@ -158,6 +158,24 @@ struct power_supply *power_supply_get_by_name(char *name)
> }
> EXPORT_SYMBOL_GPL(power_supply_get_by_name);
>
> +#ifdef CONFIG_PSY_CM_LOW_LEVEL_SUPPORT
>
On 01/04/2013 01:31:10 PM, Pantelis Antoniou wrote:
Introduce DT overlay support.
Using this functionality it is possible to dynamically overlay a part
of
the kernel's tree with another tree that's been dynamically loaded.
It is also possible to remove node and properties.
Signed-off-by:
On Sat, Jan 05, 2013 at 06:16:31PM -0800, Eric Dumazet wrote:
> On Sat, 2013-01-05 at 17:51 -0800, Eric Dumazet wrote:
> > On Sat, 2013-01-05 at 17:40 -0800, Eric Dumazet wrote:
> > > On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wrote:
> > >
> > > > Ah interesting because these were some of
On Tue, Nov 27, 2012 at 11:28:43AM +0530, Sachin Kamat wrote:
> This series is build tested againt the linux-next tree (20121126)
>
> Sachin Kamat (3):
> power: bq2415x_charger: Remove unneeded version.h inclusion
> power: bq2415x_charger: Use module_i2c_driver
> power: bq2415x_charger: Use
On Sun, 2013-01-06 at 03:32 +0100, Willy Tarreau wrote:
> It's 0cf833ae (net: loopback: set default mtu to 64K). And I could
> reproduce it with 3.6 by setting loopback's MTU to 65536 by hand.
> The trick is that once the MTU has been set to this large a value,
> even when I set it back to 16kB
On Fri, Nov 23, 2012 at 06:11:52PM +0530, Tushar Behera wrote:
> Add devm_* APIs for threaded IRQ.
>
> Also since devres managed objects are removed when the device gets
> detached, remove explicit freeing of them.
>
> Signed-off-by: Tushar Behera
> ---
[...]
> @@ -994,9 +988,6 @@ static int
On Sat, Jan 05, 2013 at 06:22:13PM -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 03:18 +0100, Willy Tarreau wrote:
> > On Sat, Jan 05, 2013 at 06:16:31PM -0800, Eric Dumazet wrote:
> > > On Sat, 2013-01-05 at 17:51 -0800, Eric Dumazet wrote:
> > > > On Sat, 2013-01-05 at 17:40 -0800, Eric
On Mon, Dec 03, 2012 at 02:09:02AM +, Tc, Jenny wrote:
> > > Could you please review this. This is a follow up patch for "PATCH]
> > > extcon : callback function to read cable property"
> >
> > While I see nothing wrong with the patch itself, I beg you to send some
> > users
> > for the new
On Sun, 2013-01-06 at 03:18 +0100, Willy Tarreau wrote:
> On Sat, Jan 05, 2013 at 06:16:31PM -0800, Eric Dumazet wrote:
> > On Sat, 2013-01-05 at 17:51 -0800, Eric Dumazet wrote:
> > > On Sat, 2013-01-05 at 17:40 -0800, Eric Dumazet wrote:
> > > > On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau
On Sat, Jan 05, 2013 at 06:16:31PM -0800, Eric Dumazet wrote:
> On Sat, 2013-01-05 at 17:51 -0800, Eric Dumazet wrote:
> > On Sat, 2013-01-05 at 17:40 -0800, Eric Dumazet wrote:
> > > On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wrote:
> > >
> > > > Ah interesting because these were some of
On Sat, 2013-01-05 at 17:51 -0800, Eric Dumazet wrote:
> On Sat, 2013-01-05 at 17:40 -0800, Eric Dumazet wrote:
> > On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wrote:
> >
> > > Ah interesting because these were some of the mm patches that I had
> > > tried to revert.
> >
> > Hmm, or we
Hi Shaun,
-Original Message-
From: Shaun Ruffell [mailto:sruff...@digium.com]
Sent: Saturday, January 05, 2013 9:21 AM
To: Sadasivan Shaiju
Cc: linux-kernel@vger.kernel.org; ve...@google.com; a.p.zijls...@chello.nl
Subject: Re: Incorrect accounting of irq into the running task
On Fri,
On Sat, 2013-01-05 at 17:40 -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wrote:
>
> > Ah interesting because these were some of the mm patches that I had
> > tried to revert.
>
> Hmm, or we should fix __skb_splice_bits()
>
> I'll send a patch.
>
Could you try
On Mon, Dec 03, 2012 at 11:42:55PM +0530, Rajanikanth H.V wrote:
> From: "Rajanikanth H.V"
>
> ab8500_fg driver prepares instance list of fuelgauge which is
> required by btemp driver for battery identification. So make sure
> that ab8500 fuelgauge list is ready before btemp driver starts.
>
>
On Sun, 2013-01-06 at 02:30 +0100, Willy Tarreau wrote:
> Ah interesting because these were some of the mm patches that I had
> tried to revert.
Hmm, or we should fix __skb_splice_bits()
I'll send a patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Sat, Jan 05, 2013 at 05:21:16PM -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 01:50 +0100, Willy Tarreau wrote:
>
> > Yes, I've removed all zero counters in this short view for easier
> > reading (complete version appended at the end of this email). This
> > was after around 140 GB were
On Sun, 2013-01-06 at 01:50 +0100, Willy Tarreau wrote:
> Yes, I've removed all zero counters in this short view for easier
> reading (complete version appended at the end of this email). This
> was after around 140 GB were transferred :
OK I only wanted to make sure skb were not linearized in
On Sat, Jan 05, 2013 at 04:02:03PM -0800, Eric Dumazet wrote:
> On Sun, 2013-01-06 at 00:29 +0100, Willy Tarreau wrote:
>
> > > 2) Another possibility would be that Myri card/driver doesnt like very
> > > well high order pages.
> >
> > It looks like it has not changed much since 3.6 :-/ I really
The problem continues with 3.8-rc
This is grave, no vmlinuz is produced.
wl
CC arch/x86/kernel/cpu/perf_event.o
CC arch/x86/kernel/cpu/perf_event_amd.o
CC arch/x86/kernel/cpu/perf_event_p6.o
arch/x86/kernel/cpu/perf_event_p6.c:22: error:
p6_hw_cache_event_ids causes a
[Re: [PATCH/RFC 0/1] Delete legacy power trace API] On 05/01/2013 (Sat 23:10)
Rafael J. Wysocki wrote:
> On Friday, January 04, 2013 08:49:03 PM Paul Gortmaker wrote:
> > The actual deletion is mind-numbingly simple; and if you go by the
> > comments in the code, it is well overdue. However, in
On Sun, 2013-01-06 at 00:29 +0100, Willy Tarreau wrote:
> > 2) Another possibility would be that Myri card/driver doesnt like very
> > well high order pages.
>
> It looks like it has not changed much since 3.6 :-/ I really suspect
> something is wrong with memory allocation. I have tried
Reviewed-by: Steve Wise
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 1/5/2013 7:37 AM, Akinobu Mita wrote:
2013/1/5 Steve Wise :
I'm asking: why are you bothering with renaming the functions? This seems
like a needless change, _unless_ there are really non-pseudo-random services
being added.
We already have get_random_byte() which is not pseudo-random
Hi Eric,
On Sat, Jan 05, 2013 at 03:18:46PM -0800, Eric Dumazet wrote:
> Hi Willy, another good finding during the week end ! ;)
Yes, I wanted to experiment with TFO and stopped on this :-)
> 1) This looks like interrupts are spreaded on multiple cpus, and this
> give Out Of Order problems with
On Sat, Jan 05, 2013 at 04:50:58PM +0530, Laxman Dewangan wrote:
> HI Dmitry,
> Thanks for quick review.
>
> I will take care of your comment in next version. Some have my answer.
>
>
> On Saturday 05 January 2013 01:36 PM, Dmitry Torokhov wrote:
> >Hi Laxman,
> >
> >On Sat, Jan 05, 2013 at
On Sat, 2013-01-05 at 22:49 +0100, Willy Tarreau wrote:
> Hi,
>
> I'm observing multiple apparently unrelated network performance
> issues in 3.7, to the point that I'm doubting it comes from the
> network stack.
>
> My setup involves 3 machines connected point-to-point with myri
> 10GE NICs
On Sat, Jan 05, 2013 at 02:09:05PM -0500, Nickolai Zeldovich wrote:
> In drivers/input/keyboard/lm8323.c, INT_PWM1 is already a bitmask,
> not the bit number, so shifting by INT_PWM1 is incorrect.
>
> Signed-off-by: Nickolai Zeldovich
Applied, thank you Nickolai.
> ---
>
Larry Finger wrote:
Woody,
There is a patch pending that fixes this problem. See
http://lkml.indiana.edu/hypermail/linux/kernel/1212.3/01201.html. Note
that Rafael wrote "If you don't mind, I'll rename
CONFIG_CPU_FREQ_GOVERNOR to
CONFIG_CPU_FREQ_GOV_COMMON when applying it, though". I think
On Fri, Dec 21, 2012 at 05:56:51PM -0800, Tejun Heo wrote:
> There's no need to test whether a (delayed) work item in pending
> before queueing, flushing or cancelling it. Most uses are unnecessary
> and quite a few of them are buggy.
>
> Remove unnecessary pending tests and rewrite
On Thu, Nov 22, 2012 at 04:44:15PM +0900, Chanwoo Choi wrote:
> This patch fix bug related to checking fully charged state of battery
> when charger-manager call is_full_charged() function. After reading
> property of charger/fuel-gauge through power_supply API, val.intval is
> more than 1. So,
On Friday, January 04, 2013 08:49:03 PM Paul Gortmaker wrote:
> The actual deletion is mind-numbingly simple; and if you go by the
> comments in the code, it is well overdue. However, in discussions
> with Frederic, he suggested to me that those comments might have
> been overly optimistic, and
On Fri, Jan 4, 2013 at 9:10 PM, Yinghai Lu wrote:
> On Fri, Jan 4, 2013 at 6:02 PM, Shuah Khan wrote:
>> I applied your patch to 3.6.11 and changed the panic() to pr_info()
>> and also changed enough_mem_for_swiotlb() to always return false to
>> simulate not enough memory condition as this
On Saturday, January 05, 2013 10:31:11 AM Sedat Dilek wrote:
> Hi Rafael,
>
> against which Linux-kernel version is your patchset?
> Linux v3.8-rc2?
> Mambo number 5 [1] aka patch 5/6 does not apply cleanly.
Oh, I didn't say, sorry about that.
It is on top of the linux-next branch of the
Hi,
I'm observing multiple apparently unrelated network performance
issues in 3.7, to the point that I'm doubting it comes from the
network stack.
My setup involves 3 machines connected point-to-point with myri
10GE NICs (the middle machine has 2 NICs). The middle machine
normally runs haproxy,
On Saturday, January 05, 2013 10:43:31 AM Sedat Dilek wrote:
> Just a small typo in the comments:
> ...
> +#ifdef CONFIG_PM
> ...
> +#else /* !CONFIG_PM */
> ...
> +#endif /* !CONFIG_PM */ <--- /* CONFIG_PM (without "!") */
This actually isn't a typo. It meas that the block started by #else ends
On Saturday, January 05, 2013 09:39:41 AM Woody Suwalski wrote:
> Rafael, in 3.8 kernel part of the common logic has been moved to a
> separate cpufreq_governor.c file.
> According to the Makefile, the cpufreq_governor.o is to be linked to
> other cpufreq modules.
>
> However I see that a
Le jeudi 03 janvier 2013 à 10:19 +0100, Takashi Iwai a écrit :
> At Fri, 28 Dec 2012 15:25:40 +0100,
> Vincent Blut wrote:
> >
> > Hi,
> >
> > Since I updated to Linux 3.7.1, listening to some audio/video bits
> > frequently cause the following:
> >
> > [ 7896.166946] hda-intel:
On Thu, Dec 13, 2012 at 03:21:23PM +, Lee Jones wrote:
> Please find the next instalment of the AB8500 Power drivers upgrade.
> A lot of work has taken place on the internal development track, but
> little effort has gone into mainlining it. At last count there were
> around 70+ patches which
Woody,
There is a patch pending that fixes this problem. See
http://lkml.indiana.edu/hypermail/linux/kernel/1212.3/01201.html. Note that
Rafael wrote "If you don't mind, I'll rename CONFIG_CPU_FREQ_GOVERNOR to
CONFIG_CPU_FREQ_GOV_COMMON when applying it, though". I think this patch is
working
On 01/04/13 15:44, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2013-01-04-15-43 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my
On Sat, 2013-01-05 at 17:34 +0800, Jason Wang wrote:
> Currently, tun_chr_poll() returns POLLERR after waitqueue adding during device
> unregistration. This would confuse some of its user such as vhost which assume
> when POLLERR is returned, it wasn't added to the waitqueue. Fix this by
>
Indeed. The same happens in synth_add, so Greg please use this instead:
Check that array index is in-bounds before accessing the synths[] array.
Signed-off-by: Nickolai Zeldovich
Signed-off-by: Samuel Thibault
---
drivers/staging/speakup/synth.c |4 ++--
1 file changed, 2 insertions(+),
On Sat, 2013-01-05 at 14:19 -0500, Nickolai Zeldovich wrote:
> Fix an inverted null pointer check in initiate_bulk_draining().
>
> Signed-off-by: Nickolai Zeldovich
> ---
> fs/nfs/callback_proc.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/nfs/callback_proc.c
The current calculation in pfn_to_bitidx assumes that
(pfn - zone->zone_start_pfn) >> pageblock_order will return the
same bit for all pfn in a pageblock. If zone_start_pfn is not
aligned to pageblock_nr_pages, this may not always be correct.
Consider the following with pageblock order = 10, zone
On Thu, Dec 20, 2012 at 04:41:37PM +0100, Stephane Eranian wrote:
> This patch adds PERF_SAMPLE_COST and PERF_SAMPLE_DSRC.
> The first collects a cost associated with the sampled
> event. In case of memory access, the cost would be
> the latency of the load, otherwise it defaults to
> the sampling
On Thu, Dec 20, 2012 at 04:41:38PM +0100, Stephane Eranian wrote:
> This patch adds support for memory profiling using the
> PEBS Load Latency facility.
>
> Load accesses are sampled by HW and the instruction
> address, data address, load latency, data source, tlb,
> locked information can be
On Thu, Dec 20, 2012 at 04:41:37PM +0100, Stephane Eranian wrote:
> This patch adds PERF_SAMPLE_COST and PERF_SAMPLE_DSRC.
I guess PERF_SAMPLE_COST was replaced by PERF_SAMPLE_WEIGHT added by Andi
jirka
> The first collects a cost associated with the sampled
> event. In case of memory access,
2013/1/5 Paul E. McKenney :
> On Sat, Jan 05, 2013 at 06:21:01PM +0100, Frederic Weisbecker wrote:
>> Hi Paul,
>>
>> 2013/1/5 Paul E. McKenney :
>> > From: Paul Gortmaker
>> >
>> > The wait_event() at the head of the rcu_nocb_kthread() can result in
>> > soft-lockup complaints if the CPU in
Cleanup. And I think we need more cleanups, in particular
__set_current_blocked() and sigprocmask() should die. Nobody
should ever block SIGKILL or SIGSTOP.
- Change set_current_blocked() to use __set_current_blocked()
- Change sys_sigprocmask() to use set_current_blocked(), this
way it should
On 01/05, CAI Qian wrote:
>
> FYI, I noticed that ssetmask/sgetmask syscalls starting to
> fail
>
> ssetmask011 TFAIL : sgetmask() failed: TEST_ERRNO=???(0): Success
Thanks!
Should be fixed by 1/2. Probably trivial enough for 3.8
2/2 is a minor "while at it" cleanup.
Oleg.
--
To
77097ae5 "most of set_current_blocked() callers want SIGKILL/SIGSTOP
removed from set" removed the initialization of newmask by accident,
restore.
Reported-by: CAI Qian
Signed-off-by: Oleg Nesterov
Cc: sta...@kernel.org # v3.5+
---
kernel/signal.c |1 +
1 files changed, 1 insertions(+),
On Sat, Jan 05, 2013 at 06:21:01PM +0100, Frederic Weisbecker wrote:
> Hi Paul,
>
> 2013/1/5 Paul E. McKenney :
> > From: Paul Gortmaker
> >
> > The wait_event() at the head of the rcu_nocb_kthread() can result in
> > soft-lockup complaints if the CPU in question does not register RCU
> >
From: "Paul E. McKenney"
Currently, the only way to specify no-CBs CPUs is via the rcu_nocbs
kernel command-line parameter. This is inconvenient in some cases,
particularly for randconfig testing, so this commit adds a new
RCU_NOCB_CPU_DEFAULT kernel configuration parameter. Setting this
new
On 12/22/2012 08:52 PM, Sergei Shtylyov wrote:
>> please respin this patch with a real commit log.
>And then, when referring to commit ID that broke da8xx.c don't forget to
> also
> specify the commit summmary in parens (or however you like).
Also, please s/davinci/da8xx/ in the
From: "Paul E. McKenney"
Currently, CPU 0 is constrained to not be a no-CBs CPU, and furthermore
at least one no-CBs CPU must remain online at any given time. These
restrictions are problematic in some situations, such as cases where
all CPUs must run a real-time workload that needs to be
rcu: Provide RCU CPU stall warnings for tiny RCU
Tiny RCU has historically omitted RCU CPU stall warnings in order to
reduce memory requirements, however, lack of these warnings caused Thomas
Gleixner some debugging pain recently. Therefore, this commit adds RCU
CPU stall warnings to tiny RCU if
From: "Paul E. McKenney"
Currently, callbacks are advanced each time the corresponding CPU
notices a change in its leaf rcu_node structure's ->completed value
(this value counts grace-period completions). This approach has worked
quite well, but with the advent of RCU_FAST_NO_HZ, we cannot
From: "Paul E. McKenney"
If CPUs are to give prior notice of needed grace periods, it will be
necessary to invoke rcu_start_gp() without dropping the root rcu_node
structure's ->lock. This commit takes a second step in this direction
by moving the release of this lock to rcu_start_gp()'s
From: "Paul E. McKenney"
This commit adds event tracing for callback acceleration to allow better
tracking of callbacks through the system.
Signed-off-by: Paul E. McKenney
---
include/trace/events/rcu.h |6 --
kernel/rcutree.c |6 ++
2 files changed, 10
From: "Paul E. McKenney"
CPUs going idle will need to record the need for a future grace
period, but won't actually need to block waiting on it. This commit
therefore splits rcu_start_future_gp(), which does the recording, from
rcu_nocb_wait_gp(), which now invokes rcu_start_future_gp() to do
From: "Paul E. McKenney"
RCU_FAST_NO_HZ operation is controlled by four compile-time C-preprocessor
macros, but some use cases benefit greatly from runtime adjustment,
particularly when tuning devices. This commit therefore creates the
corresponding sysfs entries.
Reported-by: Robin Randhawa
From: "Paul E. McKenney"
Now that callback acceleration is idempotent, it is safe to accelerate
callbacks during grace-period cleanup on any CPUs that the kthread happens
to be running on. This commit therefore propagates the completion
of the grace period to the per-CPU data structures, and
From: "Paul E. McKenney"
Dyntick-idle CPUs need to be able to pre-announce their need for grace
periods. This can be done using something similar to the mechanism used
by no-CB CPUs to announce their need for grace periods. This commit
moves in this direction by renaming the no-CBs
From: "Paul E. McKenney"
Now that rcu_start_future_gp() has been abstracted from
rcu_nocb_wait_gp(), rcu_accelerate_cbs() can invoke rcu_start_future_gp()
so as to register the need for any future grace periods needed by a
CPU about to enter dyntick-idle mode. This commit makes this change.
From: "Paul E. McKenney"
Currently, the per-no-CBs-CPU kthreads are named "rcuo" followed by
the CPU number, for example, "rcuo". This is problematic given that
there are either two or three RCU flavors, each of which gets a per-CPU
kthread with exactly the same name. This commit therefore
From: "Paul E. McKenney"
If CPUs are to give prior notice of needed grace periods, it will be
necessary to invoke rcu_start_gp() without dropping the root rcu_node
structure's ->lock. This commit takes a first step in this direction
by moving the release of this lock to the end of
From: "Paul E. McKenney"
CPUs going idle need to be able to indicate their need for future grace
periods. A mechanism for doing this already exists for no-callbacks
CPUs, so the idea is to re-use that mechanism. This commit therefore
moves the ->n_nocb_gp_requests field of the rcu_node
From: "Paul E. McKenney"
Because RCU callbacks are now associated with the number of the grace
period that they must wait for, CPUs can now take advance callbacks
corresponding to grace periods that ended while a given CPU was in
dyntick-idle mode. This eliminates the need to try forcing the
Hello!
This series contains changes to RCU_FAST_NO_HZ idle entry/exit and also
removes restrictions on no-CBs CPUs. This series contains some commits
that are still rather experimental, so you should avoid using these patches
unless you would like to help debug them. ;-)
1. Tag callback
We recently managed to crash 10 of our test machines at the same time.
Half of the machines were running a 3.1.9 kernel and half were running
3.4.9. I realize that these are both fairly old kernels but I've
skimmed the list of fixes in the 3.4.* stable series and didn't see
anything that appeared
Jörg Otte :
[...]
> jojo@ahorn:~$ dmesg | grep XID
> [1.808847] r8169 :02:00.0 eth0: RTL8168evl/8111evl at
> 0xc9054000, 5c:9a:d8:69:2b:39, XID 0c900800 IRQ 42
Can you check if things improve with v3.8-rc2 after removing :
1. 9ecb9aabaf634677c77af467f4e3028b09d7bcda
r8169:
On Fri, Jan 04, 2013 at 10:22:12AM -0800, Sadasivan Shaiju wrote:
> Hi Venkatesh,
>
> I have applied the following patches for the incorrect accounting
> of irq into the running task .
>
>
> [PATCH] x86: Add IRQ_TIME_ACCOUNTING
> [e82b8e4ea4f3dffe6e7939f90e78da675fcc450e]
> [PATCH] sched: Add
Hi Paul,
2013/1/5 Paul E. McKenney :
> From: Paul Gortmaker
>
> The wait_event() at the head of the rcu_nocb_kthread() can result in
> soft-lockup complaints if the CPU in question does not register RCU
> callbacks for an extended period. This commit therefore changes
> the wait_event() to a
On Fri, Jan 04, 2013 at 10:33:53AM -0800, Paul E. McKenney wrote:
> On Fri, Jan 04, 2013 at 12:59:40PM -0500, Cody P Schafer wrote:
> > Small gramar fix in rcutree comment regarding 'rcu_scheduler_active'
> > var.
>
> Queued, thank you! I could not resist fixing a small nit in the commit
> log
On Sat, Jan 05, 2013 at 09:09:20AM -0800, Paul E. McKenney wrote:
> Hello!
>
> The following fixes are intended for 3.9:
>
> 1.Fix int/long type confusion in trace_rcu_start_batch().
> 2.Declare rcu_is_cpu_rrupt_from_idle() static, courtesy of
> Josh Triplett.
> 3.Make
From: Josh Triplett
Both rcutiny and rcutree define a helper function named
rcu_is_cpu_rrupt_from_idle(), each used exactly once, later in the
same file. This commit therefore declares these helper functions static.
Signed-off-by: Josh Triplett
Signed-off-by: Paul E. McKenney
---
From: Li Zhong
This patch uses the real new value of dynticks_nesting instead of 0 in
rcu_eqs_enter_common().
Signed-off-by: Li Zhong
Signed-off-by: Paul E. McKenney
---
kernel/rcutree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/rcutree.c
From: "Paul E. McKenney"
When the type of global variable blimit changed from int to long, the
type of the blimit argument of trace_rcu_batch_start() needed to have
changed. This commit fixes this issue.
Signed-off-by: Paul E. McKenney
---
include/trace/events/rcu.h |6 +++---
1 files
From: "Paul E. McKenney"
It turns out that gcc 4.8 warns on array indexes being out of bounds
unless it can prove otherwise. It gives this warning on some RCU
initialization code. Because this is far from any fastpath, add
an explicit check for array bounds and panic if so. This gives the
From: Sasha Levin
Signed-off-by: Sasha Levin
Reviewed-by: Josh Triplett
Signed-off-by: Paul E. McKenney
---
kernel/rcutorture.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/rcutorture.c b/kernel/rcutorture.c
index 31dea01..0249800 100644
---
From: Cody P Schafer
Small grammar fix in rcutree comment regarding 'rcu_scheduler_active'
var.
Signed-off-by: Paul E. McKenney
---
kernel/rcutree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index e0d9815..d78ba60 100644
---
1 - 100 of 386 matches
Mail list logo
