On 10/14/19 12:24 PM, Steven Rostedt wrote:
> On Thu, 10 Oct 2019 11:51:17 -0700
> "Srivatsa S. Bhat" wrote:
>
>> From: Srivatsa S. Bhat (VMware)
>>
>> Update the source file name in the comments, and fix a grammatical
>> error.
>
> Patch
From: Srivatsa S. Bhat (VMware)
Update the source file name in the comments, and fix a grammatical
error.
Signed-off-by: Srivatsa S. Bhat (VMware)
---
kernel/trace/trace_hwlat.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_hwlat.c b/kernel
From: Srivatsa S. Bhat (VMware)
max_latency is intended to record the maximum ever observed hardware
latency, which may occur in either part of the loop (inner/outer). So
we need to also consider the outer-loop sample when updating
max_latency.
Fixes: e7c15cd8a113 ("tracing: Added har
From: Srivatsa S. Bhat (VMware)
nmi_total_ts is supposed to record the total time spent in *all* NMIs
that occur on the given CPU during the (active portion of the)
sampling window. However, the code seems to be overwriting this
variable for each NMI, thereby only recording the time spent in the
subtle bug causing loss of control over I/O bandwidths
>
Thanks a lot for these patches, Paolo!
Would you mind adding:
Reported-by: Srivatsa S. Bhat (VMware)
Tested-by: Srivatsa S. Bhat (VMware)
to the first 5 patches, as appropriate?
Thank you!
>
> [1] https://lkml.org/lkml/2019/
On 5/22/19 2:12 AM, Paolo Valente wrote:
>
>> Il giorno 22 mag 2019, alle ore 11:02, Srivatsa S. Bhat
>> ha scritto:
>>
>>
>> Let's continue here on LKML itself.
>
> Just done :)
>
>> The only reason I created the
>> bugzilla entry
On 5/22/19 2:09 AM, Paolo Valente wrote:
>
> First, thank you very much for testing my patches, and, above all, for
> sharing those huge traces!
>
> According to the your traces, the residual 20% lower throughput that you
> record is due to the fact that the BFQ injection mechanism takes a few
>
From: Srivatsa S. Bhat (VMware)
To disable a tracing option using the trace_options file, the option
name needs to be prefixed with 'no', and not suffixed, as the README
states. Fix it.
Signed-off-by: Srivatsa S. Bhat (VMware)
---
kernel/trace/trace.c |2 +-
1 file changed, 1
...@redhat.com
Cc: rkrc...@redhat.com
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Srivatsa S. Bhat
Reviewed-by: Matt Helsley (VMware)
Reviewed-by: Alexey Makhalov
Reviewed-by: Bo Gan
---
arch/x86/include/asm/nospec-branch.h | 26
s Cook
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
Cc: Will Drewry
Cc: linux-kernel@vger.kernel.org
Link:
http://lkml.kernel.org/r/1462201010-16846-1-git-send-email-dvlas...@redhat.com
Signed-off-by: Ingo Molnar
Signed-off-by: Srivatsa S. Bhat
Reviewed-by: M
Zijlstra
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Srivatsa S. Bhat
Reviewed-by: Matt Helsley (VMware)
Reviewed-by: Alexey Makhalov
Reviewed-by: Bo Gan
---
arch/x86/kernel/cpu/bugs.c | 25
On 4/13/18 10:00 AM, Theodore Y. Ts'o wrote:
> On Fri, Apr 13, 2018 at 03:05:01PM +0200, Stephan Mueller wrote:
>>
>> What I would like to point out that more and more folks change to
>> getrandom(2). As this call will now unblock much later in the boot cycle,
>> these systems see a significant d
On 3/21/18 10:12 PM, Srivatsa S. Bhat wrote:
> On 3/21/18 7:02 PM, Steve French wrote:
>> Found a patch which solves the dependency issue. In my testing (on
>> 4.9, with Windows 2016, and also to Samba) as Pavel suggested this
>> appears to fix the problem, but I will let Sri
ws can fail the request if you send it unsigned
See kernel bugzilla bug 197311
[ Fixed up for kernel version 4.4 ]
CC: Stable
Acked-by: Ronnie Sahlberg
Signed-off-by: Steve French
Signed-off-by: Srivatsa S. Bhat
---
fs/cifs/smb2pdu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/c
backport a
>> slightly larger set of fixes to the older stable, but I don't have a
>> system running 4.9 stable.
>>
>> Is this the correct stable tree branch?
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-4.9.y
>>
&g
.9
and 4.4, as I'm not that familiar with the internals of SMB/CIFS. ]
> Is this the correct stable tree branch?
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-4.9.y
>
Yep!
Regards,
Srivatsa
> On Tue, Feb 27, 2018 at 11:45 AM, Srivatsa S
On 2/27/18 4:40 AM, Greg Kroah-Hartman wrote:
> On Tue, Feb 27, 2018 at 01:22:31AM -0800, Srivatsa S. Bhat wrote:
>> On 2/27/18 12:54 AM, Greg Kroah-Hartman wrote:
>>> On Mon, Feb 26, 2018 at 07:44:28PM -0800, Srivatsa S. Bhat wrote:
>>>> On 1/3/18 6:15 PM, Srivatsa S
On 2/27/18 12:54 AM, Greg Kroah-Hartman wrote:
> On Mon, Feb 26, 2018 at 07:44:28PM -0800, Srivatsa S. Bhat wrote:
>> On 1/3/18 6:15 PM, Srivatsa S. Bhat wrote:
>>> On 11/1/17 8:18 AM, Greg Kroah-Hartman wrote:
>>>> On Tue, Oct 31, 2017 at 03:02:11PM +0200, Th
On 1/3/18 6:15 PM, Srivatsa S. Bhat wrote:
> On 11/1/17 8:18 AM, Greg Kroah-Hartman wrote:
>> On Tue, Oct 31, 2017 at 03:02:11PM +0200, Thomas Backlund wrote:
>>> Den 31.10.2017 kl. 11:55, skrev Greg Kroah-Hartman:
>>>> 4.13-stable review patch. If anyone has
On 2/6/18 2:24 AM, Greg KH wrote:
> On Mon, Feb 05, 2018 at 06:25:27PM -0800, Srivatsa S. Bhat wrote:
>> From: Srivatsa S. Bhat
>>
>> register_blkdev() and __register_chrdev_region() treat the major
>> number as an unsigned int. So print it the same way to avoid
>>
From: Srivatsa S. Bhat
register_blkdev() and __register_chrdev_region() treat the major
number as an unsigned int. So print it the same way to avoid
absurd error statements such as:
"... major requested (-1) is greater than the maximum (511) ..."
(and also fix off-by-one bugs in the er
From: Srivatsa S. Bhat
CHRDEV_MAJOR_DYN_END and CHRDEV_MAJOR_DYN_EXT_END are valid major
numbers. So fix the loop iteration to include them in the search for
free major numbers.
While at it, also remove a redundant if condition ("cd->major != i"),
as it will never be true.
On 2/1/18 5:10 PM, Logan Gunthorpe wrote:
>
>
> On 01/02/18 05:23 PM, Srivatsa S. Bhat wrote:
>> static int find_dynamic_major(void)
>> {
>> int i;
>> struct char_device_struct *cd;
>>
>> for (i = ARRAY
On 1/31/18 6:24 AM, Greg KH wrote:
> On Tue, Jan 30, 2018 at 04:56:32PM -0800, Srivatsa S. Bhat wrote:
>>
>> Hi,
>>
>> Before commit 133d55cdb2f "block: order /proc/devices by major number",
>> if register_blkdev() was called with major = [1..UIN
Hi Logan,
On 1/30/18 5:26 PM, Logan Gunthorpe wrote:
>
>
> On 30/01/18 05:56 PM, Srivatsa S. Bhat wrote:
>> If the restriction on the major number was intentional, perhaps we
>> should get the LTP testcase modified for kernel versions >= 4.14.
>> Otherwise, we
Hi,
Before commit 133d55cdb2f "block: order /proc/devices by major number",
if register_blkdev() was called with major = [1..UINT_MAX], it used to
succeed (provided the requested major number was actually free).
However, while fixing the ordering in /proc/devices, commit 133d55cdb2f
also added t
Hi Aurélien,
On 1/19/18 5:23 AM, Aurélien Aptel wrote:
> Hi,
>
> "Srivatsa S. Bhat" writes:
>>> Any thoughts on what is the right fix for stable kernels? Mounting SMB3
>>> shares works great on mainline (v4.15-rc5). It also works on 4.4.109 if
>>&g
On 1/3/18 6:15 PM, Srivatsa S. Bhat wrote:
> On 11/1/17 8:18 AM, Greg Kroah-Hartman wrote:
>> On Tue, Oct 31, 2017 at 03:02:11PM +0200, Thomas Backlund wrote:
>>> Den 31.10.2017 kl. 11:55, skrev Greg Kroah-Hartman:
>>>> 4.13-stable review patch. If anyone has
On 11/1/17 8:18 AM, Greg Kroah-Hartman wrote:
> On Tue, Oct 31, 2017 at 03:02:11PM +0200, Thomas Backlund wrote:
>> Den 31.10.2017 kl. 11:55, skrev Greg Kroah-Hartman:
>>> 4.13-stable review patch. If anyone has any objections, please let me know.
>>>
>>> --
>>>
>>> From: Steve Fre
a variable which is updated under
> the hotplug lock and let the users interested deal with it w/o
> imposing that extra state checks on everyone.
>
> Signed-off-by: Thomas Gleixner
> Cc: linux-a...@vger.kernel.org
> Cc: Rik van Riel
> Cc: Rafael Wysocki
> Cc: "S
a variable which is updated under
> the hotplug lock and let the users interested deal with it w/o
> imposing that extra state checks on everyone.
>
> Signed-off-by: Thomas Gleixner
> Cc: linux-a...@vger.kernel.org
> Cc: Rik van Riel
> Cc: Rafael Wysocki
> Cc: "S
Cc: Rik van Riel
> Cc: Rafael Wysocki
> Cc: "Srivatsa S. Bhat"
> Cc: Peter Zijlstra
> Cc: Arjan van de Ven
> Cc: Sebastian Siewior
> Cc: Rusty Russell
> Cc: Steven Rostedt
> Cc: Oleg Nesterov
> Cc: Tejun Heo
> Cc: Andrew Morton
> Cc:
inus Torvalds
> Cc: Paul Turner
> Link: http://lkml.kernel.org/r/20160226182340.429389...@linutronix.de
> Signed-off-by: Thomas Gleixner
> ---
Reviewed-by: Srivatsa S. Bhat
Regards,
Srivatsa S. Bhat
> kernel/cpu.c | 69
> +
/lkml.org/lkml/2014/7/1/473
https://lkml.org/lkml/2014/7/4/16
I didn't find this fix in mainline yet, so I thought of sending a note.
Thank you!
Regards,
Srivatsa S. Bhat
> Because of a collision with 8d056c48e486 ("CPU hotplug, smp: flush any
> pending IPI callbacks
On 07/16/2014 06:43 PM, Viresh Kumar wrote:
> On 16 July 2014 16:46, Srivatsa S. Bhat wrote:
>> Short answer: If the sysfs directory has already been created by cpufreq,
>> then yes, it will remain as it is. However, if the online operation failed
>> before that, then cpu
releasing the hotplug lock, and POST_DEAD stage
was well-suited for that.
Commit 1aee40ac9c8 (cpufreq: Invoke __cpufreq_remove_dev_finish() after
releasing cpu_hotplug.lock) explains this in detail. Saravana, please take a
look at that reasoning and ensure that your patch doesn't re
On 07/16/2014 11:14 AM, Viresh Kumar wrote:
> On 15 July 2014 12:28, Srivatsa S. Bhat wrote:
>> Wait, allowing an offline CPU to be the policy->cpu (i.e., the CPU which is
>> considered as the master of the policy/group) is just absurd.
>
> Yeah, that was as Absurd as I
On 07/15/2014 11:05 PM, skan...@codeaurora.org wrote:
>
> Srivatsa S. Bhat wrote:
>> On 07/15/2014 11:06 AM, Saravana Kannan wrote:
>>> On 07/14/2014 09:35 PM, Viresh Kumar wrote:
>>>> On 15 July 2014 00:38, Saravana Kannan wrote:
>>>>> Yeah, it
particular case -
if we can't achieve the simplification by keeping sane semantics, then we
shouldn't do the simplification!
That said, I think we should keep trying - we haven't exhausted all ideas
yet :-)
Regards,
Srivatsa S. Bhat
> So, even if we are sure cpufreq.c is fine, it
code later, but at
this point, splitting up this patch into multiple smaller, reviewable pieces
(accompanied by well-written changelogs that explain the intent) is the utmost
priority. Just like Viresh, even I had a hard time reviewing all of this in
one go.
Thank you for taking up this work!
r_info() at the end of the function that tells us that
we successfully registered the driver. We can do the same thing for
unregistration as well.)
>
> subsys_interface_unregister(&cpufreq_interface);
> if (cpufreq_boost_supported())
>
Regards,
Srivatsa S. Bhat
--
T
On 06/25/2014 09:12 PM, Sasha Levin wrote:
> On 05/26/2014 07:08 AM, Srivatsa S. Bhat wrote:
>> During CPU offline, in stop-machine, we don't enforce any rule in the
>> _DISABLE_IRQ stage, regarding the order in which the outgoing CPU and the
>> other
>> CPUs disab
On 06/25/2014 10:08 PM, Peter Zijlstra wrote:
> On Wed, Jun 25, 2014 at 10:23:21AM -0600, Stephen Warren wrote:
>> On 06/25/2014 04:19 AM, Peter Zijlstra wrote:
>>> On Wed, Jun 25, 2014 at 03:24:11PM +0530, Srivatsa S. Bhat wrote:
>>>> Wait, that was a stupid idea.
On 06/25/2014 03:49 PM, Peter Zijlstra wrote:
> On Wed, Jun 25, 2014 at 03:24:11PM +0530, Srivatsa S. Bhat wrote:
>> Wait, that was a stupid idea. hotplug_cfd() already invokes irq_work_run
>> indirectly via flush_smp_call_function_queue(). So irq_work_cpu_notify()
>> does
On 06/25/2014 03:20 PM, Srivatsa S. Bhat wrote:
> On 06/25/2014 03:09 PM, Peter Zijlstra wrote:
>> On Wed, Jun 25, 2014 at 11:36:57AM +0200, Peter Zijlstra wrote:
>>> On Wed, Jun 25, 2014 at 12:07:05PM +0530, Srivatsa S. Bhat wrote:
>>>> I don't think irqs_disa
On 06/25/2014 03:09 PM, Peter Zijlstra wrote:
> On Wed, Jun 25, 2014 at 11:36:57AM +0200, Peter Zijlstra wrote:
>> On Wed, Jun 25, 2014 at 12:07:05PM +0530, Srivatsa S. Bhat wrote:
>>> I don't think irqs_disabled() is the problematic condition, since
>>> hotplug_c
fix for that.
Regards,
Srivatsa S. Bhat
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit 68c90b2c635f18ad51ae7440162f6c082ea1288d
> Merge: f08af6f ec11f8c
> Author: Stephen Rothwell
> AuthorDate: Mon Jun 23 14:12:48 2014 +1000
>
> M
don't think irqs_disabled() is the problematic condition, since
hotplug_cfg() invokes irq_work_run() from CPU_DYING context (which has
irqs disabled). I guess you meant to remove the in_irq() check inside
irq_work_run() instead?
Regards,
Srivatsa S. Bhat
> if (llist_empty(list))
>
On 06/17/2014 05:25 PM, Sachin Kamat wrote:
> Hi Srivatsa,
>
> On Tue, Jun 17, 2014 at 3:24 PM, Srivatsa S. Bhat
> wrote:
>> On 06/17/2014 03:03 PM, Sachin Kamat wrote:
>>
>>>> Below is an updated patch, please let me know how it goes. (You'll have
t tree in which
I have reverted the 2 old commits and added this updated patch.
git://github.com/srivatsabhat/linux.git ipi-offline-fix-v3
]
----
From: Srivatsa S. Bhat
[PATCH] CPU hotplug, smp: Execute any pending IPI callback
47a9d7cca - CPU hotplug, smp: Execute any pending IPI callbacks before CPU
offline]
[56e692182 - CPU hotplug, smp: flush any pending IPI callbacks before CPU
offline]
Andrew, can you please use this patch instead?
Thanks a lot!
--
On 06/15/2014 12:56 PM, Jet Chen wrote:
> Hi Srivatsa,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit ab7a42783d939cdbe729c18ab32dbf0d25746ea2
> Author:
Hi Joel,
On 06/12/2014 12:09 PM, Joel Stanley wrote:
> Hi Srivatsa,
>
> On Sat, Jun 7, 2014 at 7:16 AM, Srivatsa S. Bhat
> wrote:
>> And with the following hunk added (which I had forgotten earlier), it worked
>> just
>> fine on powernv :-)
>
> How are the
il that is done).
[a...@linux-foundation.org: coding-style fixes]
Signed-off-by: Srivatsa S. Bhat
Suggested-by: Frederic Weisbecker
Cc: "Paul E. McKenney"
Cc: Borislav Petkov
Cc: Christoph Hellwig
Cc: Frederic Weisbecker
Cc: Gautham R Shenoy
Cc: Ingo Molnar
Cc: Mel Gorman
Cc: Mi
Extend the year to 2014 in the copyright.
Signed-off-by: Srivatsa S. Bhat
---
Documentation/power/suspend-and-cpuhotplug.txt |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/power/suspend-and-cpuhotplug.txt
b/Documentation/power/suspend-and-cpuhotplug.txt
On 06/09/2014 04:53 PM, Srivatsa S. Bhat wrote:
> But what about .mailmap? Can I add to that? I guess I can, since that's not
> related to copyrights and it is meant to handle email-id changes and such.
>
Ah, nevermind.. mailmap only helps if we want to update our name (if it was
On 06/09/2014 04:58 PM, Rafael J. Wysocki wrote:
> On Monday, June 09, 2014 03:54:49 PM Srivatsa S. Bhat wrote:
>> My @linux.vnet.ibm.com email address is going to disappear soon, as I will be
>> beginning my M.S./PhD studies at MIT in a few months.
>
> Congratulati
On 06/09/2014 04:02 PM, Viresh Kumar wrote:
> On 9 June 2014 15:54, Srivatsa S. Bhat
> wrote:
>> My @linux.vnet.ibm.com email address is going to disappear soon, as I will be
>> beginning my M.S./PhD studies at MIT in a few months. So update my email
>> addr
My @linux.vnet.ibm.com email address is going to disappear soon, as I will be
beginning my M.S./PhD studies at MIT in a few months. So update my email
address in the documentation.
Signed-off-by: Srivatsa S. Bhat
Signed-off-by: Srivatsa S. Bhat
---
Documentation/power/suspend-and
ome under it.
>
> Also checkpatch is made more silent as it was reporting this (--strict
> option):
>
> CHECK: Alignment should match open parenthesis
> + if (unlikely(wall_time > (2 * sampling_rate) &&
> +
a touch-up to the comment would be worthwhile. Something
like this:
Used to keep track of the load in the previous interval. However, when
explicitly set to zero, it is used as a flag to ensure that we copy the
previous load to the current interval only once, upon the first wake-up
from idle.
>*/
> - bool copy_prev_load;
> + unsigned int prev_load;
> struct cpufreq_policy *cur_policy;
> struct delayed_work work;
> /*
>
Thank you!
Regards,
Srivatsa S. Bhat
--
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/
, workloads that are truly latency-sensitive will benefit
quite a bit from this change. Moreover, this is an overall win-win since this
patch does not hurt power-savings at all (because, this patch does not reduce
the idle time or idle residency; and the high frequency of the CPU when it goes
to cpu
r ramp-up, even if it
was an idle interval.
Below is an untested patch that implements that logic (and it also fixes the
64 bit division problem reported by Fengguang's build robot in the v2 of the
patch).
I'll test this patch and then send out the v3 later today. Please let me
kno
On 06/07/2014 03:07 AM, Rafael J. Wysocki wrote:
> On Wednesday, June 04, 2014 03:17:00 AM Srivatsa S. Bhat wrote:
>> Cpufreq governors like the ondemand governor calculate the load on the CPU
>> periodically by employing deferrable timers. A deferrable timer won't fire
>>
On 06/06/2014 05:59 PM, Srivatsa S. Bhat wrote:
> On 06/04/2014 03:39 AM, Benjamin Herrenschmidt wrote:
>> On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote:
>>> Yep, that makes sense. But unfortunately I don't have enough insight into
>>> why exactly power
On 06/06/2014 11:57 PM, Vivek Goyal wrote:
> On Fri, Jun 06, 2014 at 06:00:43PM +0530, Srivatsa S. Bhat wrote:
>> On 06/04/2014 07:16 PM, Vivek Goyal wrote:
>>> On Wed, Jun 04, 2014 at 08:09:25AM +1000, Benjamin Herrenschmidt wrote:
>>>> On Wed, 2014-06-04 at 01:58
On 06/06/2014 05:59 PM, Srivatsa S. Bhat wrote:
> +bool kexec_cpu_wake(void)
> +{
> + kexec_smp_down(NULL);
> +
> + /* NOTREACHED */
> + return true;
> +}
> +
This function doesn't have to return anything, so we can define it as void.
The bool is a remn
On 06/04/2014 07:11 PM, Vivek Goyal wrote:
> On Wed, Jun 04, 2014 at 01:58:40AM +0530, Srivatsa S. Bhat wrote:
>> On 05/28/2014 07:01 PM, Vivek Goyal wrote:
>>> On Tue, May 27, 2014 at 04:25:34PM +0530, Srivatsa S. Bhat wrote:
>>>> If we try to perform a kexec whe
On 06/04/2014 07:16 PM, Vivek Goyal wrote:
> On Wed, Jun 04, 2014 at 08:09:25AM +1000, Benjamin Herrenschmidt wrote:
>> On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote:
>>> Yep, that makes sense. But unfortunately I don't have enough insight into
>>> why e
On 06/04/2014 03:39 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote:
>> Yep, that makes sense. But unfortunately I don't have enough insight into
>> why exactly powerpc has to online the CPUs before doing a kexec. I just
>> kn
SMP and hence the better solution is to exclude subcore.o and
> subcore-asm.o for UP builds.
>
> Signed-off-by: Shreyas B. Prabhu
Reviewed-by: Srivatsa S. Bhat
Regards,
Srivatsa S. Bhat
> ---
> Changes in v2:
> Excluding subcore-asm.o which is part of the subcore feature for
On 06/05/2014 12:56 PM, Peter Zijlstra wrote:
> On Thu, Jun 05, 2014 at 01:37:25AM +0530, Srivatsa S. Bhat wrote:
>> On 06/05/2014 01:17 AM, Peter Zijlstra wrote:
>>> On Thu, Jun 05, 2014 at 01:09:35AM +0530, Srivatsa S. Bhat wrote:
>>>> The current implementation
On 06/05/2014 01:17 AM, Peter Zijlstra wrote:
> On Thu, Jun 05, 2014 at 01:09:35AM +0530, Srivatsa S. Bhat wrote:
>> The current implementation of lockless list (llist) has a drawback: if we
>> want to traverse the list in FIFO order (oldest to newest), we need to
>> revers
RN_ON case.
Signed-off-by: Srivatsa S. Bhat
---
kernel/smp.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/smp.c b/kernel/smp.c
index 5295388..be55094 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -229,7 +229,6 @@ static void flush_smp_call_function_
ncy-sensitive will benefit
quite a bit from this change. Moreover, this is an overall win-win since this
patch does not hurt power-savings at all (because, this patch does not reduce
the idle time or idle residency; and the high frequency of the CPU when it goes
to cpu-idle does not affect/hurt the pow
On 05/28/2014 07:01 PM, Vivek Goyal wrote:
> On Tue, May 27, 2014 at 04:25:34PM +0530, Srivatsa S. Bhat wrote:
>> If we try to perform a kexec when the machine is in ST (Single-Threaded) mode
>> (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we
On 06/03/2014 03:46 PM, Viresh Kumar wrote:
> On 3 June 2014 15:43, Srivatsa S. Bhat
> wrote:
>> diff --git a/drivers/cpufreq/cpufreq_governor.c
>> b/drivers/cpufreq/cpufreq_governor.c
>> index e1c6433..2597bbe 100644
>> --- a/drivers/cpufreq/cpufreq_gover
On 06/03/2014 03:38 PM, Viresh Kumar wrote:
> On 3 June 2014 15:34, Srivatsa S. Bhat
> wrote:
>> Well, the method I used keeps the organization such that the code following
>> the comment does precisely what the comment says (i.e, get the sampling_rate,
>> fetch the multi
On 06/03/2014 03:09 PM, Viresh Kumar wrote:
> On 3 June 2014 15:02, Srivatsa S. Bhat
> wrote:
>> diff --git a/drivers/cpufreq/cpufreq_governor.c
>> b/drivers/cpufreq/cpufreq_governor.c
>> index e1c6433..3e8588f 100644
>> --- a/drivers/cpufreq/cpufreq_gover
On 06/03/2014 01:48 PM, Viresh Kumar wrote:
> On 27 May 2014 02:23, Srivatsa S. Bhat
> wrote:
>
> Looks fine, some nits..
>
>> diff --git a/drivers/cpufreq/cpufreq_governor.c
>> b/drivers/cpufreq/cpufreq_governor.c
>> -void dbs_check_cpu(struct dbs_
On 06/03/2014 10:46 AM, Gautham R Shenoy wrote:
> On Mon, Jun 02, 2014 at 01:45:38PM +0530, Srivatsa S. Bhat wrote:
>> On 06/02/2014 01:03 PM, Gautham R Shenoy wrote:
>>> Hi,
>>>
>>> On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote:
>>>
On 06/02/2014 01:03 PM, Gautham R Shenoy wrote:
> Hi,
>
> On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote:
>
> [..snip..]
>>
>> Experimental results:
>>
>>
>> I ran a modified version of ebizzy (called &#x
xec: migrate to reboot cpu)
Cc: sta...@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat
---
arch/powerpc/kernel/machine_kexec_64.c |2 +-
kernel/kexec.c |8
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
On 05/27/2014 04:57 AM, Rafael J. Wysocki wrote:
> Hi Srivatsa,
>
> On Tuesday, May 27, 2014 02:23:38 AM Srivatsa S. Bhat wrote:
>> Cpufreq governors like the ondemand governor calculate the load on the CPU
>> periodically by employing deferrable timers. A deferrable timer
ncy-sensitive will benefit
quite a bit from this change. Moreover, this is an overall win-win since this
patch does not hurt power-savings at all (because, this patch does not reduce
the idle time or idle residency; and the high frequency of the CPU when it goes
to cpu-idle does not affec
e right solution here is to fix CPU hotplug to mark the
CPU offline _after_ invoking the CPU_DYING notifiers, but this requires a
lot of audit to ensure that this change doesn't break any existing code;
hence lets go with the solution proposed above until that is done).
Suggested-by: Frederic Wei
-data linked list and print out the payload (i.e., the name
of the function which was supposed to be executed by the target CPU). This
would give us an insight as to who might have sent the IPI and help us debug
this further.
Signed-off-by: Srivatsa S. Bhat
---
kernel/smp.c | 18 +++-
LTI_STOP_DISABLE_IRQ state into two:
MULTI_STOP_DISABLE_IRQ_INACTIVE and MULTI_STOP_DISABLE_IRQ_ACTIVE, and
used this framework to ensure that the CPU going offline always disables
its interrupts last. Suggested by Tejun Heo.
v1 and v2:
https://lkml.org/lkml/2014/5/6/474
Srivatsa S. Bhat (2):
On 05/26/2014 04:30 PM, Rafael J. Wysocki wrote:
> On Monday, May 26, 2014 02:01:14 PM Srivatsa S. Bhat wrote:
>> On 05/23/2014 06:33 PM, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki
>>>
>>> On some systems the platform doesn't support neither
>
work
with systems that support only the freeze state. However, for the reasons
mentioned above, I hope that this is a temporary solution and we can remove
or enhance this once all those user-space frameworks have been fixed.
Regards,
Srivatsa S. Bhat
> For this reason, add a new kernel comman
On 05/23/2014 09:23 PM, Srivatsa S. Bhat wrote:
> On 05/23/2014 09:18 PM, Peter Zijlstra wrote:
>> On Fri, May 23, 2014 at 09:07:18PM +0530, Srivatsa S. Bhat wrote:
>>> On 05/23/2014 09:03 PM, Srivatsa S. Bhat wrote:
>>>> On 05/23/2014 09:01 PM, Peter Zijlstra wrote:
On 05/23/2014 09:18 PM, Peter Zijlstra wrote:
> On Fri, May 23, 2014 at 09:07:18PM +0530, Srivatsa S. Bhat wrote:
>> On 05/23/2014 09:03 PM, Srivatsa S. Bhat wrote:
>>> On 05/23/2014 09:01 PM, Peter Zijlstra wrote:
>>>> On Fri, May 23, 2014 at 08:48:07PM +0530, Sriva
On 05/23/2014 09:03 PM, Srivatsa S. Bhat wrote:
> On 05/23/2014 09:01 PM, Peter Zijlstra wrote:
>> On Fri, May 23, 2014 at 08:48:07PM +0530, Srivatsa S. Bhat wrote:
>>> On 05/23/2014 08:42 PM, Peter Zijlstra wrote:
>>>> On Fri, May 23, 2014 at 08:15:35PM
On 05/23/2014 09:01 PM, Peter Zijlstra wrote:
> On Fri, May 23, 2014 at 08:48:07PM +0530, Srivatsa S. Bhat wrote:
>> On 05/23/2014 08:42 PM, Peter Zijlstra wrote:
>>> On Fri, May 23, 2014 at 08:15:35PM +0530, Srivatsa S. Bhat wrote:
>>>>>> + * D
On 05/23/2014 08:51 PM, Peter Zijlstra wrote:
> On Fri, May 23, 2014 at 03:42:20PM +0530, Srivatsa S. Bhat wrote:
>>Re-enable interrupts Re-enable interrupts
>>
>> The
On 05/23/2014 08:34 PM, Frederic Weisbecker wrote:
> On Fri, May 23, 2014 at 08:15:35PM +0530, Srivatsa S. Bhat wrote:
>> On 05/23/2014 06:52 PM, Frederic Weisbecker wrote:
>>> On Fri, May 23, 2014 at 03:42:20PM +0530, Srivatsa S. Bhat wrote:
>>>> During CPU offline
On 05/23/2014 08:42 PM, Peter Zijlstra wrote:
> On Fri, May 23, 2014 at 08:15:35PM +0530, Srivatsa S. Bhat wrote:
>>>> + * During CPU offline, we don't want the other CPUs to send
>>>> + * IPIs to the active_cpu (the outgoing CPU) *after* it
On 05/23/2014 06:57 PM, Frederic Weisbecker wrote:
> On Fri, May 23, 2014 at 03:42:35PM +0530, Srivatsa S. Bhat wrote:
>> During CPU offline, in the stop-machine loop, we use 2 separate stages to
>> disable interrupts, to ensure that the CPU going offline doesn't get any new
&g
On 05/23/2014 06:52 PM, Frederic Weisbecker wrote:
> On Fri, May 23, 2014 at 03:42:20PM +0530, Srivatsa S. Bhat wrote:
>> During CPU offline, stop-machine is used to take control over all the online
>> CPUs (via the per-cpu stopper thread) and then run take_cpu_down() on the CPU
&
-data linked list and print out the payload (i.e., the name
of the function which was supposed to be executed by the target CPU). This
would give us an insight as to who might have sent the IPI and help us debug
this further.
Signed-off-by: Srivatsa S. Bhat
---
kernel/smp.c | 18 +++-
1 - 100 of 1351 matches
Mail list logo
