wait_noreap_copyout(struct wait_opts *wo,
struct task_struct *p,
{
struct waitid_info *infop;
- if (wo->wo_rusage)
- getrusage(p, RUSAGE_BOTH, wo->wo_rusage);
-
put_task_struct(p);
infop = wo->wo_info;
if (infop) {
@@ -1099,6 +1096,8 @@ s
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Zijlstra
commit 173be9a14f7b2e901cf77c18b1aafd4d672e9d9e upstream.
Mike reports:
Roughly 10% of the time, ltp testcase getrusage04 fails:
getrusage040 TINFO : Expected timers gr
4.7-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Zijlstra
commit 173be9a14f7b2e901cf77c18b1aafd4d672e9d9e upstream.
Mike reports:
Roughly 10% of the time, ltp testcase getrusage04 fails:
getrusage040 TINFO : Expected timers gr
On Mon, 2016-08-15 at 10:51 +0200, Peter Zijlstra wrote:
> On Wed, Aug 10, 2016 at 08:57:28PM +0200, Mike Galbraith wrote:
> >
> > +> >> > /*
> > +> >> > * sum_exec_runtime has moved, but nothing has yet been
> > +> >> > * accounted to the task, there's nothing to update
On Wed, Aug 10, 2016 at 08:57:28PM +0200, Mike Galbraith wrote:
> sched/cputime: Fix NO_HZ_FULL getrusage() monotonicity regression
>
> Roughly 10% of the time, ltp testcase getrusage04 fails:
> getrusage040 TINFO : Expected timers granularity is 4000 us
> getrusage040
On Wed, Aug 10, 2016 at 01:14:29PM +0200, Mike Galbraith wrote:
> Hi Peter,
>
> While running ltp, the fates decided it was time for me to encounter
> the roughly 1 out of every 10 call failure below. As much as I run
> ltp, I'm a bit surprised that I (or anyone else) haven't met this
> before, b
Hi Peter,
While running ltp, the fates decided it was time for me to encounter
the roughly 1 out of every 10 call failure below. As much as I run
ltp, I'm a bit surprised that I (or anyone else) haven't met this
before, but then the fates are known to be a tad fickle.
getrusage040 TINFO :
goto update;
> > }
>
> This cannot be right; it violates that utime+stime==rtime. Let me try
> and figure out what actually happens.
How about this instead.
sched/cputime: Fix NO_HZ_FULL getrusage() monotonicity regression
Roughly 10% of the time, ltp testcase g
On Wed, 2016-08-10 at 14:47 +0200, Peter Zijlstra wrote:
> Any idea where your [us]time are coming from? Do you end up in the
> vtime_accounting_enabled() path or not?
No, I'm not booting with nohz_full=.
-Mike
On Wed, Aug 10, 2016 at 02:30:33PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 10, 2016 at 01:14:29PM +0200, Mike Galbraith wrote:
> > Hi Peter,
> >
> > While running ltp, the fates decided it was time for me to encounter
> > the roughly 1 out of every 10 call failure below. As much as I run
> > l
ction ‘get_cpu_usage_nsec_parent’:
builtin-sched.c:399:16: error: storage size of ‘ru’ isn’t known
builtin-sched.c:403:2: error: implicit declaration of function ‘getrusage’
[-Werror=implicit-function-declaration]
[...]
Fix it by including sys/resource.h.
Signed-off-by: Markus Trippelsdorf
Cc:
From: Frederic Weisbecker
Both syscalls need to iterate through the thread group to get
the cputimes. As some threads of the group may be running on
nohz cpuset, we need to flush the cputimes there.
Signed-off-by: Frederic Weisbecker
Cc: Alessio Igor Bogani
Cc: Andrew Morton
Cc: Avi Kivity
C
Eric W. Biederman wrote:
> Pavel Emelyanov <[EMAIL PROTECTED]> writes:
>>> ...
>>> +asmlinkage long sys_thread_getrusage(int tid, struct rusage __user *ru)
>>> +{
>>> + struct task_struct *tsk;
>>> + tsk = find_task_by_pid(tid);
>>&g
;>> +{
>>>> + struct task_struct *tsk;
>>>> + tsk = find_task_by_pid(tid);
>>>> + return getrusage(tsk, RUSAGE_THREAD, ru);
>>>> +}
>>> Well, the find_task_by_pid() is really wrong here.
>> And find_task_by_pid should probably j
ruct *tsk;
> >> + tsk = find_task_by_pid(tid);
> >> + return getrusage(tsk, RUSAGE_THREAD, ru);
> >> +}
> >
> > Well, the find_task_by_pid() is really wrong here.
>
> And find_task_by_pid should probably just be removed.
That's what I was think
Pavel Emelyanov <[EMAIL PROTECTED]> writes:
>> ...
>> +asmlinkage long sys_thread_getrusage(int tid, struct rusage __user *ru)
>> +{
>> +struct task_struct *tsk;
>> +tsk = find_task_by_pid(tid);
>> +return getrusage(tsk, RUSAGE_THREAD, ru);
ead rusage' thread and didn't find any.
>
> From: Vinay Sridhar <[EMAIL PROTECTED]>
> To: linux-kernel@vger.kernel.org, [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: [RFC] Per-thread getrusage
Ouch. T
m: Vinay Sridhar <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org, [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [RFC] Per-thread getrusage
...
+asmlinkage long sys_thread_getrusage(int tid, struct rusage __user *ru)
+{
+ struct
All,
>>>>
>>>> Last year, there was discussion about per-thread getrusage by adding
>>>> RUSAGE_THREAD flag to getrusage(). Please refer to the thread
>>>> http://lkml.org/lkml/2007/4/4/308. Ulrich had suggested that we should
>>>> de
On Mon, 28 Jan 2008 13:54:12 +0530 Sripathi Kodi <[EMAIL PROTECTED]> wrote:
> Does Roland's patch (http://lkml.org/lkml/2008/1/18/589) look good to go
> in, provided Ulrich's comment (http://lkml.org/lkml/2008/1/19/15) is
> addressed?
Sure, it looks sane - it avoids the problematic get_task_by_
On Mon, 28 Jan 2008 10:48:23 +0300 Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Thu, 17 Jan 2008 13:57:05 +0530 Vinay Sridhar <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi All,
> >>
> >> Last yea
Hi Andrew,
On Monday 28 January 2008 11:22, Andrew Morton wrote:
> On Thu, 17 Jan 2008 13:57:05 +0530 Vinay Sridhar
<[EMAIL PROTECTED]> wrote:
> > Hi All,
> >
> > Last year, there was discussion about per-thread getrusage by
> > adding RUSAGE_THREAD flag to
Andrew Morton wrote:
> On Thu, 17 Jan 2008 13:57:05 +0530 Vinay Sridhar <[EMAIL PROTECTED]>
> wrote:
>
>> Hi All,
>>
>> Last year, there was discussion about per-thread getrusage by adding
>> RUSAGE_THREAD flag to getrusage(). Please refer to the thre
On Thu, 17 Jan 2008 13:57:05 +0530 Vinay Sridhar <[EMAIL PROTECTED]>
wrote:
> Hi All,
>
> Last year, there was discussion about per-thread getrusage by adding
> RUSAGE_THREAD flag to getrusage(). Please refer to the thread
> http://lkml.org/lkml/2007/4/4/308. Ulri
I agree that RUSAGE_THREAD is fine. (In fact, if you'd pressed me to
remember without looking, I would have assumed we put it in already.)
However, in the implementation, I would keep it cleaner by moving the
identical code from inside the loop under case RUSAGE_SELF into a shared
subfunction, rat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vinay Sridhar wrote:
> There are two ways to implement this in the kernel:
> 1) Introduce an additional parameter 'tid' to sys_getrusage() and put
> code in glibc to handle getrusage() and pthread_getrusage() calls
> correctly
Hi All,
Last year, there was discussion about per-thread getrusage by adding
RUSAGE_THREAD flag to getrusage(). Please refer to the thread
http://lkml.org/lkml/2007/4/4/308. Ulrich had suggested that we should
design a better user-space API. Specifically, we need a
pthread_getrusage interface in
On Thu, 20 Sep 2007 10:57:19 -0700 Frank Mayhar <[EMAIL PROTECTED]> wrote:
> Properly support the ru_maxrss field of the rusage structure returned by
> getrusage(). This patch includes documentation both of the getrusage()
> implementation in general and of the ru_maxrss
Frank Mayhar wrote:
Properly support the ru_maxrss field of the rusage structure returned by
getrusage().
Signed-off-by: Frank Mayhar <[EMAIL PROTECTED]>
Acked-by: Rik van Riel <[EMAIL PROTECTED]>
--
All Rights Reversed
-
To unsubscribe from this list: send the line "
Properly support the ru_maxrss field of the rusage structure returned by
getrusage(). This patch includes documentation both of the getrusage()
implementation in general and of the ru_maxrss implementation
specifically. This implementation matches that of FreeBSD, which is the
only other OS of
For some reason, the first twenty times I read the doc, I missed the
"terminated and waited-for" bit for RUSAGE_CHILDREN.
Patch withdrawn, for the moment anyway. (And the right fix won't solve
our problem, sigh.)
--
Frank Mayhar <[EMAIL PROTECTED]>
Google, Inc.
-
To unsubscribe from this list:
->ru_maxrss += hiwater_rss;
break;
default:
---
Like a number of other folks, we recently had a need for a non-/proc way
of getting the RSS of a process and happened on getrusage(). Unlike the
rest, though, we fixed the system call to do what we want.
The code its
Hello all,
I've been doing some getrusage tests using this:
#include
#include
#include
int main(void)
{
unsigned int i;
struct rusage ru;
for(i=1;i;i++) asm volatile("nop");
getrusage(RUSAGE_SELF, &ru);
printf("%dsec %dusec\n",ru.ru_utime.tv_sec,ru
On Mon, 19 Mar 2007 17:37:23 +0300
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> On 03/19, Eric Dumazet wrote:
> >
> > [...snip...]
> > do {
> > utime = cputime_add(utime, t->utime);
> > @@ -2040,6 +2045,8 @@ static void k_getrusage(struct task_stru
> >
On Mon, 19 Mar 2007 17:37:23 +0300
Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> (offtopic)
Well..., it *is* ontopic I'm afraid...
>
> We are reading u64 read_bytes/write_bytes which could be updated
> asynchronously.
> /proc/pid/io does the same.
>
> Of course, I don't blame this patch, just a
On 03/19, Eric Dumazet wrote:
>
> [...snip...]
> do {
> utime = cputime_add(utime, t->utime);
> @@ -2040,6 +2045,8 @@ static void k_getrusage(struct task_stru
> r->ru_nivcsw += t->nivcsw;
>
accumulate inblock/oublock of terminated and waited-for
children, and terminated threads.
Thank you
[PATCH, take3] getrusage() : Fill ru_inblock and ru_oublock fields if possible
If CONFIG_TASK_IO_ACCOUNTING is defined, we update io accounting counters for
each task.
This patch permits reporting of
On Monday 19 March 2007 11:53, Oleg Nesterov wrote:
> On 03/19, Eric Dumazet wrote:
> > +static inline unsigned long task_io_get_inblock(const struct task_struct
> > *p) +{
> > + return p->ioac.read_bytes >> 9;
> > +}
> >
> > [...snip...]
> >
> > @@ -2021,6 +2022,8 @@ static void k_getrusage(stru
On 03/19, Eric Dumazet wrote:
>
> +static inline unsigned long task_io_get_inblock(const struct task_struct *p)
> +{
> + return p->ioac.read_bytes >> 9;
> +}
>
> [...snip...]
>
> @@ -2021,6 +2022,8 @@ static void k_getrusage(struct task_stru
> r->ru_nivcsw = p->signal->cni
accumulate inblock/oublock of terminated and waited-for
children.
Thank you
[PATCH, take2] getrusage() : Fill ru_inblock and ru_oublock fields if possible
If CONFIG_TASK_IO_ACCOUNTING is defined, we update io accounting counters for
each task.
This patch permits reporting of these values using
On 03/16, Eric Dumazet wrote:
>
> On Friday 16 March 2007 18:10, Oleg Nesterov wrote:
> > Eric Dumazet wrote:
> > > @@ -2021,6 +2022,8 @@ static void k_getrusage(struct task_stru
> > > r->ru_nivcsw = p->signal->cnivcsw;
> > > r->ru_minflt = p->signal->cmin_flt;
>
On Friday 16 March 2007 18:23, Eric Dumazet wrote:
>
> Very good point, you found a bug in k_getrusage().
>
> I just followed the existing logic, but it seems this logic is bad.
>
> So not only ru_inblock/ru_oublock are multiplied by 3 : others fields as
> well are wrong.
>
> Also the definition o
On Friday 16 March 2007 18:10, Oleg Nesterov wrote:
> Eric Dumazet wrote:
> > @@ -2021,6 +2022,8 @@ static void k_getrusage(struct task_stru
> > r->ru_nivcsw = p->signal->cnivcsw;
> > r->ru_minflt = p->signal->cmin_flt;
> > r->ru_majflt =
Eric Dumazet wrote:
>
> @@ -2021,6 +2022,8 @@ static void k_getrusage(struct task_stru
> r->ru_nivcsw = p->signal->cnivcsw;
> r->ru_minflt = p->signal->cmin_flt;
> r->ru_majflt = p->signal->cmaj_flt;
> + r->ru_inb
if CONFIG_TASK_IO_ACCOUNTING is defined, we update io accounting counters for
each task.
This patch permits reporting of values using the well known getrusage()
syscall, filling ru_inblock and ru_oublock instead of null values.
As TASK_IO_ACCOUNTING currently counts bytes counts, we
On Wed, 14 Feb 2007, Johann Schuster wrote:
> currently i'm trying to measure the cpu times for
> numerical algorithms written in C using two calls of
> getrusage() and then calculating the time difference.
>
> According to the man page of getrusage i looked at the
>
Hello,
currently i'm trying to measure the cpu times for
numerical algorithms written in C using two calls of
getrusage() and then calculating the time difference.
According to the man page of getrusage i looked at the
user time of my process. Surprisingly the measured user
times vary str
Hi!
Is getrusage properly implemented in 2.6?
The man pages state:
Right now (Linux 2.4, 2.6) only the fields
ru_utime, ru_stime, ru_minflt, ru_majflt, and ru_nswap are maintained.
but some tests comparing UDP and TCP sending operations give some strange
numbers for both the user and
"J . A . Magallon" wrote:
> I have just the same problem. getrusage() did not catch the CPU time for
> children, even if the man page said that. Now I am using times(2), that
> seems to work in Solaris, but gives nothing in Linux.
>
> I you look at time(1) manpage, it
On 20010618 Dan Kegel wrote:
>Pete Wyckoff wrote:
>>
>> [EMAIL PROTECTED] said:
>> > I'd like to monitor CPU, memory, and I/O utilization in a
>> > long-running multithreaded daemon under kernels 2.2, 2.4,
>> > and possibly also Solaris (#ifde
Pete Wyckoff wrote:
>
> [EMAIL PROTECTED] said:
> > I'd like to monitor CPU, memory, and I/O utilization in a
> > long-running multithreaded daemon under kernels 2.2, 2.4,
> > and possibly also Solaris (#ifdefs are ok).
>
> getrusage() isn't really the
[EMAIL PROTECTED] said:
> I'd like to monitor CPU, memory, and I/O utilization in a
> long-running multithreaded daemon under kernels 2.2, 2.4,
> and possibly also Solaris (#ifdefs are ok).
>
> getrusage() looked promising, and might even work for CPU utilization.
> Dunno
I'd like to monitor CPU, memory, and I/O utilization in a
long-running multithreaded daemon under kernels 2.2, 2.4,
and possibly also Solaris (#ifdefs are ok).
getrusage() looked promising, and might even work for CPU utilization.
Dunno if it returns info for all child threads yet, ha
53 matches
Mail list logo
