* Jan Kiszka [2020-04-30 14:59:50]:
> >I believe ivshmem2_virtio requires hypervisor to support PCI device emulation
> >(for life-cycle management of VMs), which our hypervisor may not support. A
> >simple shared memory and doorbell or message-queue based transport will work
> >for
> >us.
>
> A
* Will Deacon [2020-04-30 11:41:50]:
> On Thu, Apr 30, 2020 at 04:04:46PM +0530, Srivatsa Vaddagiri wrote:
> > If CONFIG_VIRTIO_MMIO_OPS is defined, then I expect this to be
> > unconditionally
> > set to 'magic_qcom_ops' that uses hypervisor-supported in
* Will Deacon [2020-04-30 11:39:19]:
> Hi Vatsa,
>
> On Thu, Apr 30, 2020 at 03:59:39PM +0530, Srivatsa Vaddagiri wrote:
> > > What's stopping you from implementing the trapping support in the
> > > hypervisor? Unlike the other patches you sent out, whe
* Michael S. Tsirkin [2020-04-30 06:07:56]:
> On Thu, Apr 30, 2020 at 03:32:55PM +0530, Srivatsa Vaddagiri wrote:
> > The Type-1 hypervisor we are dealing with does not allow for MMIO
> > transport.
>
> How about PCI then?
Correct me if I am wrong, but basically virtio_
* Will Deacon [2020-04-30 11:14:32]:
> > +#ifdef CONFIG_VIRTIO_MMIO_OPS
> >
> > +static struct virtio_mmio_ops *mmio_ops;
> > +
> > +#define virtio_readb(a)mmio_ops->mmio_readl((a))
> > +#define virtio_readw(a)mmio_ops->mmio_readl((a))
> > +#define virtio_readl(a)
* Will Deacon [2020-04-30 11:08:22]:
> > This patch is meant to seek comments. If its considered to be in right
> > direction, will work on making it more complete and send the next version!
>
> What's stopping you from implementing the trapping support in the
> hypervisor? Unlike the other patc
: Srivatsa Vaddagiri
---
drivers/virtio/virtio_mmio.c | 131 ++-
include/linux/virtio.h | 14 +
2 files changed, 94 insertions(+), 51 deletions(-)
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 97d5725..69bfa35 100644
methods
introduced allows for seamless IO of config space.
This patch is meant to seek comments. If its considered to be in right
direction, will work on making it more complete and send the next version!
1. https://lkml.org/lkml/2020/4/28/427
Srivatsa Vaddagiri (1):
virtio: Introduce MMIO ops
* Michael S. Tsirkin [2020-04-29 06:20:48]:
> On Wed, Apr 29, 2020 at 03:39:53PM +0530, Srivatsa Vaddagiri wrote:
> > That would still not work I think where swiotlb is used for pass-thr devices
> > (when private memory is fine) as well as virtio devices (when shared memory
>
* Michael S. Tsirkin [2020-04-29 05:52:05]:
> > > So it seems that with modern Linux, all one needs
> > > to do on x86 is mark the device as untrusted.
> > > It's already possible to do this with ACPI and with OF - would that be
> > > sufficient for achieving what this patchset is trying to do?
>
* Michael S. Tsirkin [2020-04-29 02:50:41]:
> So it seems that with modern Linux, all one needs
> to do on x86 is mark the device as untrusted.
> It's already possible to do this with ACPI and with OF - would that be
> sufficient for achieving what this patchset is trying to do?
In my case, its
* Stefano Stabellini [2020-04-28 16:04:34]:
> > > Is swiotlb commonly used for multiple devices that may be on different
> > > trust
> > > boundaries (and not behind a hardware iommu)?
>
> The trust boundary is not a good way of describing the scenario and I
> think it leads to miscommunication
* Michael S. Tsirkin [2020-04-28 16:41:04]:
> > Won't we still need some changes to virtio to make use of its own pool (to
> > bounce buffers)? Something similar to its own DMA ops proposed in this
> > patch?
>
> If you are doing this for all devices, you need to either find a way
> to do this
* Michael S. Tsirkin [2020-04-28 12:17:57]:
> Okay, but how is all this virtio specific? For example, why not allow
> separate swiotlbs for any type of device?
> For example, this might make sense if a given device is from a
> different, less trusted vendor.
Is swiotlb commonly used for multipl
Move the memory allocation and free portion of swiotlb driver
into independent routines. They will be useful for drivers that
need swiotlb driver to just allocate/free memory chunks and not
additionally bounce memory.
Signed-off-by: Srivatsa Vaddagiri
---
include/linux/swiotlb.h | 17
This patch adds an interface for the swiotlb driver to recognize
a new memory pool. Upon successful initialization of the pool,
swiotlb returns a handle, which needs to be passed as an argument
for any future operations on the pool (map/unmap/alloc/free).
Signed-off-by: Srivatsa Vaddagiri
will require swiotlb memory to be
shared with backend VM). As a possible extension to this patch,
we can provide an option for virtio to make use of default
swiotlb memory pool itself, where no such conflicts may exist in
a given deployment.
Signed-off-by: Srivatsa Vaddagiri
---
drivers/virtio/Mak
.
Subsequent patches allow the swiotlb driver to work with more
than one pool of memory.
Signed-off-by: Srivatsa Vaddagiri
---
drivers/xen/swiotlb-xen.c | 4 +-
include/linux/swiotlb.h | 129 -
kernel/dma/swiotlb.c | 359 +++---
3
.
Signed-off-by: Srivatsa Vaddagiri
---
include/linux/swiotlb.h | 2 ++
kernel/dma/swiotlb.c| 20 ++--
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 8c7843f..c634b4d 100644
--- a/include/linux/swiotlb.h
e able to run virtio backend drivers as standalone programs (and not coupled
with any VMM).
Srivatsa Vaddagiri (5):
swiotlb: Introduce concept of swiotlb_pool
swiotlb: Allow for non-linear mapping between paddr and vaddr
swiotlb: Add alloc and free APIs
swiotlb: Add API to register ne
Commit-ID: 8bf46a39be910937d4c9e8d999a7438a7ae1a75b
Gitweb: http://git.kernel.org/tip/8bf46a39be910937d4c9e8d999a7438a7ae1a75b
Author: Srivatsa Vaddagiri
AuthorDate: Fri, 16 Sep 2016 18:28:51 -0700
Committer: Ingo Molnar
CommitDate: Thu, 22 Sep 2016 15:20:18 +0200
sched/fair: Fix
Commit-ID: 92b75202e5e8790905f9441ccaea2456cc4621a5
Gitweb: http://git.kernel.org/tip/92b75202e5e8790905f9441ccaea2456cc4621a5
Author: Srivatsa Vaddagiri
AuthorDate: Tue, 6 Aug 2013 14:55:41 +0530
Committer: Ingo Molnar
CommitDate: Wed, 14 Aug 2013 13:12:35 +0200
kvm: Paravirtual
Commit-ID: f9021f7fd9c8c8101c90b901053f99bfd0288021
Gitweb: http://git.kernel.org/tip/f9021f7fd9c8c8101c90b901053f99bfd0288021
Author: Srivatsa Vaddagiri
AuthorDate: Tue, 6 Aug 2013 14:55:41 +0530
Committer: H. Peter Anvin
CommitDate: Mon, 12 Aug 2013 09:03:57 -0700
kvm: Paravirtual
Commit-ID: 23f659a237e8f633f9605fdf9408a8d130ab72c9
Gitweb: http://git.kernel.org/tip/23f659a237e8f633f9605fdf9408a8d130ab72c9
Author: Srivatsa Vaddagiri
AuthorDate: Fri, 9 Aug 2013 19:52:02 +0530
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 07:54:24 -0700
kvm: Paravirtual
Commit-ID: 1e20eb8557cdabf76473b09572be8aa8a2bb9bc0
Gitweb: http://git.kernel.org/tip/1e20eb8557cdabf76473b09572be8aa8a2bb9bc0
Author: Srivatsa Vaddagiri
AuthorDate: Fri, 9 Aug 2013 19:52:01 +0530
Committer: H. Peter Anvin
CommitDate: Fri, 9 Aug 2013 07:54:18 -0700
kvm guest: Add
Commit-ID: b5eaeb3303fc3086f1d04deea48b5dfcfc4344c0
Gitweb: http://git.kernel.org/tip/b5eaeb3303fc3086f1d04deea48b5dfcfc4344c0
Author: Srivatsa Vaddagiri
AuthorDate: Tue, 6 Aug 2013 17:15:21 +0530
Committer: H. Peter Anvin
CommitDate: Thu, 8 Aug 2013 16:07:34 -0700
kvm : Paravirtual
Commit-ID: 20a89c88f7d2458e12f66d7850cf17deec7daa1c
Gitweb: http://git.kernel.org/tip/20a89c88f7d2458e12f66d7850cf17deec7daa1c
Author: Srivatsa Vaddagiri
AuthorDate: Tue, 6 Aug 2013 17:15:01 +0530
Committer: H. Peter Anvin
CommitDate: Thu, 8 Aug 2013 16:07:30 -0700
kvm guest : Add
* Russell King - ARM Linux [2013-01-05 10:36:27]:
> On Thu, Jan 03, 2013 at 06:58:38PM -0800, Srivatsa Vaddagiri wrote:
> > I also think that the
> > wait_for_completion() based wait in ARM's __cpu_die() can be replaced with a
> > busy-loop based one, as the wait
* Sergei Shtylyov [2013-01-04 16:13:42]:
> >With offline cpus no longer beeing seen in nohz mode (ts->idle_active=0), we
> >don't need the check for cpu_online() introduced in commit 7386cdbf. Offline
>
>Please also specify the summary of that commit in parens (or
> however you like).
I had
time statistics).
Cc: mho...@suse.cz
Cc: srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Srivatsa Vaddagiri
---
fs/proc/stat.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/fs/proc/stat.c b/fs/proc/stat.c
index e296572..64c3b31 100644
--- a/fs/proc/stat
ngo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: mho...@suse.cz
Cc: srivatsa.b...@linux.vnet.ibm.com
Signed-off-by: Srivatsa Vaddagiri
---
arch/arm/kernel/process.c |9 -
arch/arm/kernel/smp.c |2 +-
arch/blackfin/kernel/process.c |8
ar
On most architectures (arm, mips, s390, sh and x86) idle thread of a cpu does
not cleanly exit nohz state before dying upon hot-remove. As a result,
offline cpu is seen to be in nohz mode (ts->idle_active = 1) and its offline
time can potentially be included in total idle time reported via /proc/st
Commit-ID: 88b8dac0a14c511ff41486b83a8c3d688936eec0
Gitweb: http://git.kernel.org/tip/88b8dac0a14c511ff41486b83a8c3d688936eec0
Author: Srivatsa Vaddagiri
AuthorDate: Tue, 19 Jun 2012 17:43:15 +0530
Committer: Ingo Molnar
CommitDate: Tue, 24 Jul 2012 13:58:06 +0200
sched: Improve
On Mon, Feb 25, 2008 at 04:28:02PM +0100, Peter Zijlstra wrote:
> Vatsa, would it make sense to take just that out, or just do a full
> revert?
Peter,
6b2d7700266b9402e12824e11e0099ae6a4a6a79 and
58e2d4ca581167c2a079f4ee02be2f0bc52e8729 are related very much. The
later changes how cpu loa
On Mon, Feb 18, 2008 at 08:38:24AM +0100, Mike Galbraith wrote:
> Here, it does not. It seems fine without CONFIG_FAIR_GROUP_SCHED.
My hunch is its because of the vruntime driven preemption which shoots
up latencies (and the fact perhaps that Peter hasnt't focused more on SMP case
yet!).
Curious
On Wed, Jan 30, 2008 at 02:56:09PM +0100, Lukas Hejtmanek wrote:
> Hello,
>
> I noticed short thread in LKM regarding "sched: add vslice" causes horrible
> interactivity under load.
>
> I can see similar behavior. If I stress both CPU cores, even typing on
> keyboard suffers from huge latencies,
On Wed, Feb 13, 2008 at 10:04:44PM +0530, Dhaval Giani wrote:
> I know I am missing something, but aren't we trying to reduce latencies
> here?
I guess Peter is referring to the latency in seeing fairness results. In
other words, with single rq approach, you may require more time for the groups
t
8e2d4ca581167c2a079f4ee02be2f0bc52e8729
> > Author: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
> > Date: Fri Jan 25 21:08:00 2008 +0100
> >
> > sched: group scheduling, change how cpu load is calculated
> >
> >
> >
> > hackbench has about
On Tue, Feb 12, 2008 at 08:40:08PM +0100, Peter Zijlstra wrote:
> Yes, latency isolation is the one thing I had to sacrifice in order to
> get the normal latencies under control.
Hi Peter,
I don't have easy solution in mind either to meet both fairness
and latency goals in a acceptable way
On Thu, Jan 31, 2008 at 06:39:56PM -0800, Paul Menage wrote:
> On Jan 30, 2008 6:40 PM, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> >
> > Here are some questions that arise in this picture:
> >
> > 1. What is the relationship of the task-group in A/tasks w
Hi,
As we were implementing multiple-hierarchy support for CPU
controller, we hit some oddities in its implementation, partly related
to current cgroups implementation. Peter and I have been debating on the
exact solution and I thought of bringing that discussion to lkml.
Consider the cgr
On Tue, Jan 29, 2008 at 04:53:56PM +0100, Guillaume Chazarain wrote:
> I just thought about something to restore low latencies with
> FAIR_GROUP_SCHED, but it's possibly utter nonsense, so bear with me
> ;-) The idea would be to reverse the trees upside down. The scheduler
> would only see tasks (o
On Tue, Jan 29, 2008 at 11:57:22AM +0100, Peter Zijlstra wrote:
> On Tue, 2008-01-29 at 10:53 +0100, Peter Zijlstra wrote:
>
> > My thoughts were to make stronger use of disjoint cpu-sets. cgroups and
> > cpusets are related, in that cpusets provide a property to a cgroup.
> > However, load_balanc
On Mon, Jan 28, 2008 at 09:13:53PM +0100, Guillaume Chazarain wrote:
> Unfortunately it seems to not be completely fixed, with this script:
The maximum scheduling latency of a task with group scheduler is:
Lmax = latency to schedule group entity at level0 +
latency to sche
On Sun, Jan 27, 2008 at 09:01:15PM +0100, Guillaume Chazarain wrote:
> I noticed some strangely high wake up latencies with FAIR_USER_SCHED
> using this script:
> We have two busy loops with UID=1.
> And UID=2 maintains the running median of its wake up latency.
> I get these latencies:
>
> # .
On Sun, Jan 27, 2008 at 04:06:17PM +0100, Toralf Förster wrote:
> > The third line (giving overall cpu usage stats) is what is interesting here.
> > If you have more than one cpu, you can get cpu usage stats for each cpu
> > in top by pressing 1. Can you provide this information with and w/o
> > C
On Sat, Jan 26, 2008 at 07:46:51PM +0100, Toralf Förster wrote:
>
> The problem is the same as described here : http://lkml.org/lkml/2007/10/21/85
> If I run dnetc even with lowest prority than the CPU stays at 600 MHz
> regardless
> of any other load (eg. rsyncing, svn update, compiling, ...)
>
On Tue, Jan 22, 2008 at 05:47:34PM +0100, Peter Zijlstra wrote:
> It should not, that would be another bug, but from a quick glance at the
> code it doesn't do that.
Hmm I had it in my back of mind that printk() could sleep. Looks like
that has changed and so the patch you sent should be fine.
T
On Tue, Jan 22, 2008 at 05:25:38PM +0100, Peter Zijlstra wrote:
> @@ -1428,9 +1428,9 @@ static void print_cfs_stats(struct seq_f
> #ifdef CONFIG_FAIR_GROUP_SCHED
> print_cfs_rq(m, cpu, &cpu_rq(cpu)->cfs);
> #endif
> - lock_task_group_list();
> + rcu_read_lock();
> for_each_lea
On Sun, Jan 20, 2008 at 09:03:38AM +0530, Dhaval Giani wrote:
> > btw: writing 1 into "cpu_share" totally locks up the computer!
> >
>
> Can you please provide some more details. Can you go into another
> console (try ctrl-alt-f1) and try to reproduce the issue there. Could
> you take a photo of
On Mon, Jan 07, 2008 at 11:51:20AM +0100, Peter Zijlstra wrote:
> - figure out what to do for UID based group scheduling, the current
>implementation leaves it impossible for !root users to execute
>real time tasks by setting rt_runtime_us to 0, and it has no way
>to change it.
>
>
On Fri, Nov 30, 2007 at 01:35:13PM +0100, Ingo Molnar wrote:
> * Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>
> > Here's V2 of the cpu acccounting controller patch, which makes
> > accounting scale better on SMP systems by splitting the usage counter
> >
On Fri, Nov 30, 2007 at 01:48:33AM +0530, Srivatsa Vaddagiri wrote:
> It is indeed an important todo. Right now we take a per-group global
> lock on every accounting update (which can be very frequent) and hence
> it is pretty bad.
>
> Ingo had expressed the need to reintroduce
an be made static.
This symbol is needed in kernel/cgroup.c file, where it does this:
static struct cgroup_subsys *subsys[] = {
#include
};
and hence it cant be static. Thanks for the rest of your comments. I
have fixed them in this version below:
Signed-off-by: Srivatsa Vaddagiri <[EMA
On Thu, Nov 29, 2007 at 08:20:58PM +0100, Ingo Molnar wrote:
> ok, this looks certainly doable for v2.6.24. I've added it to the
> scheduler fixes queue and will let it brew there for a few days and send
> it to Linus after that if everything goes fine - unless anyone objects.
Thanks.
--
Rega
provide the same
accounting information.
Todo:
- Make the accounting scalable on SMP systems (perhaps
for 2.6.25)
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
include/linux/cgroup_subsys.h |6 ++
include/linux/cpu_acct.h | 14 +
init/Kconfig
On Tue, Nov 27, 2007 at 01:53:12PM +0100, Ingo Molnar wrote:
> > Fine. I will resubmit this patchset then once we are into 2.6.25
> > cycle.
>
> no need (unless you have bugfixes) i'm carrying this around in the
> scheduler git tree. (it will show up in sched-devel.git)
Cool .. Thx! It will get
On Tue, Nov 27, 2007 at 12:09:10PM +0100, Ingo Molnar wrote:
> thanks, it looks good - but the fact that we are at v4 of the patchset
> underlines the point that this is more of a v2.6.25 patchset than a
> v2.6.24 one.
Fine. I will resubmit this patchset then once we are into 2.6.25 cycle.
> Gr
overhead, two
min/max tunables are introduced (under SCHED_DEBUG) to control the rate at which
it runs.
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
include/linux/sched.h |4
kernel/sched.c| 259 --
kernel/sche
while rebalancing
shares of task groups across cpus.
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 19 +++
1 files changed, 19 insertions(+)
Index: current/kernel/sched.c
===
--- c
version of patch (v2 of Patch 3/5) has a minor impact on code size
(but should have no runtime/functional impact) for !CONFIG_FAIR_GROUP_SCHED
case, but the overall code, IMHO, is neater compared to v1 of Patch 3/5
(because of lesser #ifdefs).
I prefer v2 of Patch 3/5.
Signed-off-by: Srivatsa
version of patch (v1 of Patch 3/5) has zero impact for
!CONFIG_FAIR_GROUP_SCHED case.
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 38 ++
kernel/sched_fair.c | 31 +++
kernel/sche
group list)
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 34 ++
kernel/sched_fair.c |4 +++-
2 files changed, 29 insertions(+), 9 deletions(-)
Index: current/kernel/s
Minor cleanups:
- Fix coding style
- remove obsolete comment
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 21 +++--
1 files changed, 3 insertions(+), 18 deletions(-)
Index: current/kernel/s
On Mon, Nov 26, 2007 at 09:28:36PM +0100, Ingo Molnar wrote:
> the first SCHED_RR priority is 1, not 0 - so this call will always fail.
Thanks for spotting this bug and rest of your review comments.
Here's V4 of the patchset, aimed at improving fairness of cpu bandwidth
allocation for task groups
overhead, two
min/max tunables are introduced (under SCHED_DEBUG) to control the rate at which
it runs.
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
include/linux/sched.h |4
kernel/sched.c| 265 --
kernel/sche
version of patch (v2 of Patch 3/4) has a minor impact on code size
(but should have no runtime/functional impact) for !CONFIG_FAIR_GROUP_SCHED
case, but the overall code, IMHO, is neater compared to v1 of Patch 3/4
(because of lesser #ifdefs).
I prefer v2 of Patch 3/4.
Signed-off-by: Srivatsa
version of patch (v1 of Patch 3/4) has zero impact for
!CONFIG_FAIR_GROUP_SCHED case.
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 38 ++
kernel/sched_fair.c | 31 +++
kernel/sche
group list)
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 33 +
kernel/sched_fair.c |4 +++-
2 files changed, 28 insertions(+), 9 deletions(-)
Index: current/kernel/s
Minor cleanups:
- Fix coding style
- remove obsolete comment
Signed-off-by: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 21 +++--
1 files changed, 3 insertions(+), 18 deletions(-)
Index: current/kernel/s
Here's V3 of the group scheduler related patches, which is mainly addressing
improved fairness of cpu bandwidth allocation for task groups.
Patch 1/4 -> coding style cleanup
Patch 2/4 -> Minor group scheduling related bug fixes
Patch 3/4 (v1) -> Modifies how cpu load is calculated,
On Tue, Nov 20, 2007 at 12:24:59PM +0100, Damien Wyart wrote:
> Testing sched-cfs-v2.6.24-rc3-v24.patch on top of 2.6.24-rc3-git1
> (ignored the two "already applied" messages coming from git1 commits),
> I get a 1.00 minimum load in top, coming from the load_balance_mo thread
> staying in D-state.
63482 308 43996abdc sched.o-yes-after
--
+1295
--
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
include/linux/sched.h |4
kernel/sched.c| 278 ++
tex(task_group_mutex). Use the same mutex in
print_cfs_stats when walking the task group list.
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 55 +---
kernel/sched_fair.c |5 +++-
2 files changed, 35 i
Hi Ingo,
Here's V2 of the two patches related to group cpu scheduling I
sent a while ago:
Patch 1/2 -> Fixes minor bugs and coding style issues
Patch 2/2 -> Improves group fairness on SMP systems.
Changes since V1:
- Introduced a task_group_mutex to serialize add/removal of
On Mon, Nov 19, 2007 at 04:22:58PM +0100, Ingo Molnar wrote:
>
> * Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
>
> > - inc/dec_load() takes a load input instead of task pointer input as their
> > 2nd arg
> > - inc/dec_nr_running don't call inc/dec_loa
On Mon, Nov 19, 2007 at 02:12:01PM +0100, Ingo Molnar wrote:
> > include/linux/sched.h |4
> > kernel/sched.c| 292
> > +-
> > kernel/sched_fair.c | 95 ++--
> > kernel/sched_rt.c |2
> > kernel/sysctl.c
On Mon, Nov 19, 2007 at 02:08:03PM +0100, Ingo Molnar wrote:
> > #define for_each_leaf_cfs_rq(rq, cfs_rq) \
> > - list_for_each_entry(cfs_rq, &rq->leaf_cfs_rq_list, leaf_cfs_rq_list)
> > + list_for_each_entry_rcu(cfs_rq, &rq->leaf_cfs_rq_list, leaf_cfs_rq_list)
> >
> > /* Do the two (enqueu
402233482 340 44045ac0d sched.o-after
--
+1344
--
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
include/linux/sched.h |4
kernel/sched.c| 292 ++
Minor scheduler cleanups:
- Fix coding style
- remove obsolete comment
- Use list_for_each_entry_rcu when walking task group list
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 21 +++--
kernel/sched_fair.c |5 -
2 files chan
Hi Ingo,
Here are two patches related to group cpu scheduling.
Patch 1/2 -> Fixes minor bugs and coding style issues
Patch 2/2 -> Improves group fairness on SMP systems.
This is probably one of the last big changes related to group scheduler
that I had on my plate. Pls apply if there is n
On Wed, Nov 14, 2007 at 06:17:08PM +0300, Oleg Nesterov wrote:
> Suppose that old user_struct/task_group is freed/reused, and the task does
Shouldn't this old user actually be the root user_struct?
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Tue, Nov 13, 2007 at 12:59:59PM +0530, Balbir Singh wrote:
> Paul Menage wrote:
> > On Nov 12, 2007 11:00 PM, Balbir Singh <[EMAIL PROTECTED]> wrote:
> >> Right now, one of the limitations of the CPU controller is that
> >> the moment you create another control group, the bandwidth gets
> >> div
On Mon, Nov 12, 2007 at 10:05:24PM -0800, Paul Menage wrote:
> On Nov 12, 2007 10:00 PM, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > On second thoughts, this may be a usefull controller of its own.
> > Say I just want to "monitor" usage (for ac
On Mon, Nov 12, 2007 at 09:25:32PM -0800, Paul Menage wrote:
> Hi Linus,
>
> Please can you revert commit 62d0df64065e7c135d0002f069444fbdfc64768f,
> entitled "Task Control Groups: example CPU accounting subsystem" ?
Hi Paul,
On second thoughts, this may be a usefull controller of its own
On Fri, Nov 09, 2007 at 11:59:15AM +0100, Dmitry Adamushko wrote:
> > - The second problem exposed by this test is that task_new_fair()
> > assumes that parent and child will be part of the same group (which
> > needn't be as this test shows). As a result, cfs_rq->curr can be NULL
> > for the
in do_fork, by moving
up sched_fork().
Also introduce a NULL pointer check for 'curr' in task_new_fair().
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/fork.c |6 +++---
kern
ts runqueue in case of sched_fair class
tasks. Take care of this fact in rt_mutex_setprio(),
sched_setscheduler() and sched_move_task() routines.
Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
---
kernel/sched.c | 45 +
1 files chang
On Thu, Nov 01, 2007 at 01:20:08PM +0100, Peter Zijlstra wrote:
> On Thu, 2007-11-01 at 13:03 +0100, Peter Zijlstra wrote:
> > On Thu, 2007-11-01 at 12:58 +0100, Peter Zijlstra wrote:
> >
> > > > sched_slice() is about lantecy, its intended purpose is to ensure each
> > > > task is ran exactly onc
hierarchy.
>
> Also fixes a bug in vslice which missed a factor NICE_0_LOAD.
>
> Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
> CC: Srivatsa Vaddagiri <[EMAIL PROTECTED]>
> ---
> kernel/sched_fair.c | 42 +++---
> 1
On Wed, Oct 31, 2007 at 05:00:59PM +0100, Peter Zijlstra wrote:
> Hi,
Hi Peter,
> Commit: b9dca1e0fcb696716840a3bc8f20a6941b484dbf
>
> seems to me that by calling enqueue_fair_task() from task_new_fair() is
> wrong. The wakeup=1 in enqueue_fair_task() will cause all non-top
s/non-top/non-task?
l Menage <[EMAIL PROTECTED]>
Acked-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Oct 23, 2007 at 07:28:22PM -0700, Paul Menage wrote:
> > Good point. I think we need to subtract out the time it was waiting on
> > runqueue
> > when calculating idle time.
> >
> > |--- . . . . . . -...---|
> > t0 t1t2
On Tue, Oct 23, 2007 at 09:41:49AM -0700, Paul Menage wrote:
> > > Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
> > > milliseconds for that cgroup's tasks
> >
> > It would be nice to split this into user and sys time at some point.
>
> Sounds reasonable - but does CFS track th
On Mon, Oct 22, 2007 at 05:49:39PM -0700, Paul Menage wrote:
> Report CPU usage in CFS Cgroup directories
>
> Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
> milliseconds for that cgroup's tasks
It would be nice to split this into user and sys time at some point.
We have also
On Mon, Oct 22, 2007 at 05:49:39PM -0700, Paul Menage wrote:
> + for_each_possible_cpu(i) {
> + unsigned long flags;
> + spin_lock_irqsave(&tg->cfs_rq[i]->rq->lock, flags);
A simpler form of this would be just:
spin_lock_irqsave(&cpu_rq(i)->lock, flags)
On Mon, Oct 22, 2007 at 11:06:54PM -0700, Paul Menage wrote:
> > > + for_each_possible_cpu(i) {
> > > + unsigned long flags;
> > > + spin_lock_irqsave(&tg->cfs_rq[i]->rq->lock, flags);
> >
> > Is the lock absolutely required here?
>
> I'm not sure, I was hoping you or I
On Mon, Oct 22, 2007 at 05:49:20PM -0700, Paul Menage wrote:
> Clean up some CFS CGroup code
>
> - replace "cont" with "cgrp" in a few places in the CFS cgroup code,
This change looks good to me. Thanks for doing it.
> - use write_uint rather than write for cpu.shares write function
Minor nit:
On Mon, Oct 22, 2007 at 05:49:39PM -0700, Paul Menage wrote:
> +static u64 cpu_usage_read(struct cgroup *cgrp, struct cftype *cft)
> +{
> + struct task_group *tg = cgroup_tg(cgrp);
> + int i;
> + u64 res = 0;
> + for_each_possible_cpu(i) {
> + unsigned long flags;
> +
On Thu, Oct 18, 2007 at 09:55:13PM +0530, Srivatsa Vaddagiri wrote:
> The idle time reported in /proc/uptime (2nd field) seems to be the idle
> time of only CPU0. Shouldn't it reflect the total idle time on a SMP system?
> Do folks agree that it is a bug that needs to be fixed? If
1 - 100 of 488 matches
Mail list logo
