mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [RFC PATCH 0/4] Finer granularity and task/cgroup irq time accounting
@ 2010-05-25  0:11 Venkatesh Pallipadi
  2010-05-25  0:11 ` [RFC PATCH 1/4] sched: Track and export per task [hard|soft]irq time Venkatesh Pallipadi
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Venkatesh Pallipadi @ 2010-05-25  0:11 UTC (permalink / raw)
  To: Peter Zijlstra, Ingo Molnar, H. Peter Anvin, Thomas Gleixner,
	Balbir Singh, Paul Menage
  Cc: linux-kernel, Paul Turner

Currently, the softirq and hardirq time reporting is only done at the
CPU level. There are usecases where reporting this time against task
or task groups or cgroups will be useful for user/administrator
in terms of resource planning and utilization charging. Also, as the
accoounting is already done at the CPU level, reporting the same at
the task level does not add any significant computational overhead
other than task level storage (patch 1).

The softirq/hardirq statistics commonly done based on tick based sampling.
Though some archs have CONFIG_VIRT_CPU_ACCOUNTING based fine granularity
accounting. Having similar mechanism to get fine granularity accounting
on x86 will be a major challenge, given the state of TSC reliability
on various platforms and also the overhead it may add in common paths
like syscall entry exit.

An alternative is to have a generic (sched_clock based) and configurable
fine-granularity accounting of si and hi time which can be reported
over the /proc/<pid>/stat API (patch 2).

Patch 3 and 4 are exporting this info at the cgroup level.

Does exposing this additional info to user makes sense? Any feedback on
the way it is done in this patchset?

This precise irq time based on sched_clock() provides some potential
opportunities to handle the softirq time charging in a more fair way.
Specifically cases where an unrelated task is being penalized for
irq load on that CPU.
* With network Receive Flow Steering, for example; We can potentially
do things like not charge receive softirq time to the process that is
currently running and charge it instead to the actual consumer of
the receive (in recvmsg, for example).
* We can reduce the power of the CPU to account for softirq/hardirq
load, in order to increase the scheduler fairness for tasks running on
that CPU.

Comments?

Thanks,
Venki


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2010-05-26  6:54 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-05-25  0:11 [RFC PATCH 0/4] Finer granularity and task/cgroup irq time accounting Venkatesh Pallipadi
2010-05-25  0:11 ` [RFC PATCH 1/4] sched: Track and export per task [hard|soft]irq time Venkatesh Pallipadi
2010-05-25  0:11   ` [RFC PATCH 2/4] x86: Add IRQ_TIME_ACCOUNTING, finer accounting of irq time to task Venkatesh Pallipadi
2010-05-25  0:11     ` [RFC PATCH 3/4] sched: Generalize cpuacct usage tracking making it simpler to add new stats Venkatesh Pallipadi
2010-05-25  0:11       ` [RFC PATCH 4/4] sched: Export irq times through cpuacct cgroup Venkatesh Pallipadi
2010-05-25  6:35     ` [RFC PATCH 2/4] x86: Add IRQ_TIME_ACCOUNTING, finer accounting of irq time to task Peter Zijlstra
2010-05-25 21:40       ` Venkatesh Pallipadi
2010-05-26  6:54         ` Peter Zijlstra
2010-05-25  9:13   ` [RFC PATCH 1/4] sched: Track and export per task [hard|soft]irq time Balbir Singh
2010-05-25 21:45     ` Venkatesh Pallipadi
2010-05-25  7:00 ` [RFC PATCH 0/4] Finer granularity and task/cgroup irq time accounting Balbir Singh
2010-05-25  8:14 ` Peter Zijlstra
2010-05-25 17:05   ` Venkatesh Pallipadi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®