On Feb 16, 2008 6:14 PM, Alessandro Suardi <[EMAIL PROTECTED]> wrote:
> Feb 16 16:51:49 sandman kernel: BUG: rwlock recursion on CPU#0,
Same thing here, bisected it to:
commit 45b503548210fe6f23e92b856421c2a3f05fd034
Author: Laszlo Attila Toth balabit.hu>
Date: Tue Feb 12 22:42:09 2008 -0800
On Feb 11, 2008 2:17 PM, rzryyvzy <[EMAIL PROTECTED]> wrote:
> $ cat /proc/fs/vfs/reading_files
>
> $ cat /proc/fs/vfs/writing_files
You can try:
# echo 1 > /proc/sys/vm/block_dump
# dmesg
HTH.
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Feb 8, 2008 1:18 PM, <[EMAIL PROTECTED]> wrote:
> Long ago when the CLONE_THREAD support first went it someone thought it
> would be wise to point /proc/self at /proc/ instead of /proc/.
The last message about this conversation is:
http://lkml.org/lkml/2007/12/1/172
So I thought we would end
On Jan 4, 2008 4:19 PM, Al Viro <[EMAIL PROTECTED]> wrote:
> Umm... Actually, m_next() and m_stop() both appear to be too convoluted.
>
> * m_next() never gets v == NULL
> * the only reason why we do that mmput et.al. both from ->next() and
> ->stop() is that we try to avoid having priv->mm; why
On 1/31/08, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm, this is not a pure elimination of dead code, this will change
> behavior. For example we wont call sched_clock_idle_sleep_event() on
> !cpu_khz now. Hm?
Oops, indeed I overlooked that. OTOH, I can't see how it can happen
(in 32 bit at least)
On 1/31/08, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Does something like this help?
I made it compile by open coding undefined macros instead of
refactoring the whole file.
But it didn't affect wake up latencies.
Thanks.
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscri
On 1/31/08, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> works for me :-( (x86_64 rawhide userspace)
i386, !SMP, Fedora 8 here.
> Could you send your .config?
Here we go:
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24
# Thu Jan 31 12:33:36 2008
#
# CONFIG_64BI
On Jan 31, 2008 9:55 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Does this patch from thomas fix it as well?
Unfortunately, not.
For information, reverting just the first part of the offending commit
(sl->timer.cb_mode) fixed the problem, while reverting only the second
part (if (!hrtimer_act
On Jan 29, 2008 11:30 PM, Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> ===
> gnome-termina S 0027 0 2201 1
>f6711fb0 00200082 cb330d62 0027 f664105c 0b1e cb331880
>0027 f660d780 009e3840 080ab7d8 080ab298
This should be fold into:
4f95bd6e2b21a8c724357463f8341502d47aba13
x86: scale cyc_2_nsec according to CPU frequency
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
arch/x86/kernel/tsc_32.c | 14 +-
arch/x86/kernel/tsc_64.c | 14 +-
2 files chang
On Jan 29, 2008 6:47 AM, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> IMHO this is expected results and if someone really needs to cut down
> this latency, they can reduce sysctl_sched_latency (which will be bad
> from perf standpoint, as we will cause more cache thrashing with that).
Thank yo
Unfortunately it seems to not be completely fixed, with this script:
#!/usr/bin/python
import os
import time
SLEEP_TIME = 0.1
SAMPLES = 5
PRINT_DELAY = 0.5
def print_wakeup_latency():
times = []
last_print = 0
while True:
start = time.time()
time.sleep(SLEEP_TIME)
Hi Srivatsa,
On Jan 28, 2008 3:31 AM, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> Given that sysctl_sched_wakeup_granularity is set to 10ms by default,
> this doesn't sound abnormal.
Indeed, by lowering sched_wakeup_granularity I get much better
latencies, but lowering sched_latency seems to
Hi,
I noticed some strangely high wake up latencies with FAIR_USER_SCHED
using this script:
#!/usr/bin/python
import os
import time
SLEEP_TIME = 0.1
SAMPLES = 100
PRINT_DELAY = 0.5
def print_wakeup_latency():
times = []
last_print = 0
while True:
start = time.time()
On Jan 25, 2008 5:58 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> sure, done.
Thanks.
> what method are you using of determining quality?
I was talking about code quality: adding a dependency on jiffies does
not seems like a good idea. But also, about the clock quality, I was
focusing on getting
Hi Ingo,
Can I talk you into dropping these patches of mine from sched-devel
(or not send them to Linus):
da0f9440cdcb1edd5424de91f326de83de3fe5f9 sched: make sure jiffies is
up to date before calling __update_rq_clock()
6eb300ad38fef6db4efe177067a65aaa771596da sched: fix rq->clock
overflows dete
Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> FYI, I'm currently trying to track down where rq->clock started to
> overflow with nohz=off, and it seems to be before 2.6.23, so my patches
> are not at fault ;-) Or maybe I am dreaming and it was always
> overflowing.
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> ok. I have applied all but this one
Hmm, I couldn't find them in mingo/linux-2.6-sched-devel.git.
> i think it's much simpler to do what i have below. Could you try it on
> your box? Or if it is using ACPI idle - in that case the callbacks
> should alre
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> Correction: it was not a high res time source, it was "the scheduler's
> per-cpu, non-exported, non-coherent, warps-and-jumps-like-hell high-res
> timesource that was intentionally called the _sched_ clock" ;-)
I think the warts of cpu_clock() are fixabl
David Dillow <[EMAIL PROTECTED]> wrote:
> Patched kernel, nohz=off:
> .clock_underflows : 213887
A little bit of warning about these patches, they are WIP, that's why I
did not send them earlier. It regress nohz=off.
A bit of context: these patches aim at making sure cpu_clock() o
underflows as you did.
Thanks.
commit 20fa02359d971bdb820d238184fabd42d8018e4f
Author: Guillaume Chazarain <[EMAIL PROTECTED]>
Date: Thu Jan 10 23:36:43 2008 +0100
sched: monitor clock underflows in /proc/sched_debug
We monitor clock overflows, let's also monitor clock
the error is combined from the errors in all the synced inodes, so it
just tells that some inode in a specific fs got an error,
- nobody in the call stack is interested in this error: certainly not
pdflush, or 'void sync(2)'.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
Al Viro <[EMAIL PROTECTED]> wrote:
> How about this:
At least the task_mmu part works fine.
Tested-by: Guillaume Chazarain <[EMAIL PROTECTED]>
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Al Viro <[EMAIL PROTECTED]> wrote:
> vma_stop() doesn't need changes either...
Hmmm, not sure ;-)
$ cat /proc/1/maps
Pid: 2282, comm: cat Not tainted (2.6.24-rc6-gc2 #185)
EIP: 0060:[] EFLAGS: 00010286 CPU: 0
EIP is at vma_stop+0xd/0x21
EAX: f7c90360 EBX: f7c90360 ECX: c042b5f0 EDX:
ESI
Return an error instead of successfully reading an empty file.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Acked-by: Al Viro <[EMAIL PROTECTED]>
---
fs/proc/base.c |2 +-
fs/proc/task_mmu.c |6 +++---
fs/proc/task_nommu.c |4 ++--
3 files changed,
Return an error instead of successfully reading an empty file.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
fs/proc/base.c |2 +-
fs/proc/task_mmu.c |8 +---
fs/proc/task_nommu.c |4 ++--
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/f
Now that strangers are kept out of /proc//maps, let's welcome them
with -EPERM instead of a blank file.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
fs/proc/base.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/proc/base.c b/fs/
On Dec 13, 2007 2:48 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> 2.6.24-rc5 doesn't seem to create Makefiles in empty obj dirs anymore
Known problem ;-)
See
http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/188cbd12d7c0871b/194fbc7c94314b2c
--
Guillaume
--
To unsubscribe fro
The patch kbuild: fix building with O=.. options
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=18c32dac75b187d1a4e858f3cfdf03e844129f5e
disabled the creation of a Makefile in a new O=... directory. Restore it.
Signed-off-by: Guillaume Chazarain <[EM
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> the frequency of both cores is the maximum of what linux sets each core to;
Do you mean that the cpufreq code can be confused about the actual
frequency of the cores? That sounds like a big problem.
Thanks for any insight.
--
Guillaume
--
To unsubs
Stefano Brivio <[EMAIL PROTECTED]> wrote:
> Sorry for disappearing. Anyway, yes, those patches fixed it. Precision in
> delays isn't that good when using my crappy unstable TSC (mdelay(2000)
> causes delays between 2 and 2.9 seconds) but it's not depending on frequency
> changes anymore. So I'd sa
On Dec 10, 2007 9:42 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> although some claimed effect was on udelay()/mdelay() too.
Any specific report?
The jumping sched_clock on frequency change caused some
scheduling oddities for me, but CFS attenuated the effect.
Thanks.
--
Guillaume
--
To unsubsc
On Dec 9, 2007 7:01 PM, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > + * ns += offset to avoid sched_clock jumps with cpufreq
> > + *
> > * [EMAIL PROTECTED] "math is hard, lets go shopping!"
> > */
>
> Did john add the 'ns+=' or do comments need reorder?
I added it, but I th
On Dec 8, 2007 9:52 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> the scariest bit isnt even the scaling i think - that is a fairly
> straightforward and clean PER_CPU-ization of the global scaling factor,
> and its hookup with cpufreq events. (and the credit for that goes to
> G
Le Fri, 7 Dec 2007 15:54:18 +0100,
Ingo Molnar <[EMAIL PROTECTED]> a écrit :
> This is a version that
> is supposed fix all known aspects of TSC and frequency-change
> weirdnesses.
Tested it with frequency changes, the clock is as smooth as I like
it :-)
The only remaining sched_clock user in
Le Fri, 7 Dec 2007 14:55:25 +0100,
Ingo Molnar <[EMAIL PROTECTED]> a écrit :
> Firstly, we dont need the 'offset' anymore because cpu_clock() maintains
> offsets itself.
Yes, but a lower quality one. __update_rq_clock tries to compensate
large jumping clocks with a jiffy resolution, while my off
On Dec 7, 2007 12:18 PM, Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> Any pointer to it?
Nevermind, I found it ... in this same thread :-(
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
On Dec 7, 2007 12:13 PM, Nick Piggin <[EMAIL PROTECTED]> wrote:
> My patch should fix the worst cpufreq sched_clock jumping issue
> I think.
Any pointer to it?
Thanks.
--
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
Le Fri, 7 Dec 2007 09:51:21 +0100,
Ingo Molnar <[EMAIL PROTECTED]> a écrit :
> yeah, we can do something like this in 2.6.25 - this will improve the
> quality of sched_clock().
Thanks a lot for your interest!
I'll clean it up and resend it later. As I don't have the necessary
knowledge to do th
"Guillaume Chazarain" <[EMAIL PROTECTED]> wrote:
> On Dec 7, 2007 6:51 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > Hmrpf. sched_clock() is used for the time stamp of the printks. We
> > need to find some better solution other than killing off the tsc
On Dec 7, 2007 6:51 AM, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> Hmrpf. sched_clock() is used for the time stamp of the printks. We
> need to find some better solution other than killing off the tsc
> access completely.
Something like http://lkml.org/lkml/2007/3/16/291 that would need some ref
On 11/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i guess it was a v2.6.24 change, hence a regression that needs to be
> fixed?
It seems to be
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=01660410
So, linux 2.6.0-test6
--
Guillaume
-
To unsubscribe from this li
Hello Eric,
This fills a need I had to get the current TID in a Java program,
so I'm very interested in this change. OTOH, how will someone
not reading LKML discover that the current TID is now in
/proc/self and that it was not always the case?
I would put my 2 cents in /proc/self/task/self, this
On 11/11/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > So it's not strictly an
> > output directory, more a build directory.
> The opposite
> All output is placed there - including the configuration generated by
> the *config frontends.
I meant, it's not strictly an output directory as if I
On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Another important point is that users that know about and see CONFIG_*
> variables are kernel hackers, not the normal kconfig users.
But kconfig is mainly for kernel hackers, otherwise it would be
called CML2 ;-)
> > Also, when working on a sp
Hi Adrian,
On 11/11/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> What exactly are the use cases where someone would need this?
Glad you asked. Today, when I want to recompile a kernel while
changing a CONFIG_ option, I manually edit the .config,
remove the appropriate line and then run make oldco
Hi,
On 11/10/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> The variable K64BIT can now be used to select the
> value of CONFIG_64BIT.
Why not calling the environment variable CONFIG_64BIT,
in preparation of the day when all CONFIG_ variables can
be passed by environment variables?
--
Guillaume
On 11/6/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> The issue with "make allyesconfig" concerns me, although the same
> situation already exists with any multiple-choice configuration. What I
> guess we really want is to be able to specify a few specific choices.
I don't know enough about Kbu
On 11/2/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> What user-space tools are utilizing delay-accounting by the way?
Thanks for the plugging opportunity ;-)
http://guichaz.free.fr/misc/#iotop uses the I/O side of delay-accounting.
--
Guillaume
-
To unsubscribe from this list: send the line "un
elaborate mathematics
than taking the max are needed, but basic testing showed the expected fairness.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
include/linux/sched.h |4 ++
kernel/sched.c| 50 +++--
2007/10/30, Ingo Molnar <[EMAIL PROTECTED]>:
> fs/proc/array.c |3 ++-
> include/linux/sched.h |2 +-
> kernel/fork.c |1 +
> 3 files changed, 4 insertions(+), 2 deletions(-)
Hello Ingo,
do you think it would be possible to include the patch in your git
pull request ema
Le Sun, 21 Oct 2007 13:16:32 +0800,
Coly Li <[EMAIL PROTECTED]> a écrit :
> > This should be fixed in recent git by
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9b013e05e0289c190a53d78ca029e2f21c0e4485
> >
> Maybe we encounter same condition, at least the symbol
> > BUG: unable to handle kernel NULL pointer dereference at virtual address
> > 0004
This should be fixed in recent git by
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9b013e05e0289c190a53d78ca029e2f21c0e4485
HTH.
--
Guillaume
-
To unsubscribe from this list
> + mapping_set_error(mapping, ret);
And of course, s/ret/err/ :-(
--
Guillaume
-
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
ecall that the errors are
not to be found in the return value but in mapping->flags. That's why
I'd like to see sync_sb_inodes-propagate-errors.patch dropped. Removing
this patch causes some churn in -mm but I can prepare patches to fix
this up if needed.
Thanks for reading my moani
Le Wed, 26 Sep 2007 13:01:44 -0700,
Andrew Morton <[EMAIL PROTECTED]> a écrit :
> Also, I don't think we're seeing enough review and test from people on
> these patch series - I don't have time to do it all. (Well, apparently I
> do, but I don't think it's a good situation).
I don't object to yo
Le Wed, 26 Sep 2007 22:47:54 +0200,
roel <[EMAIL PROTECTED]> a écrit :
> > + if (thread_group_leader(tsk) && ((tsk->flags & PF_FORKNOEXEC)))
>
> if (thread_group_leader(tsk) && (tsk->flags & PF_FORKNOEXEC))
Yeah, right, good catch.
> > + group_exit_code = tg_stats ? tsk->signal->group
Le Sat, 22 Sep 2007 23:36:29 +0530,
Balbir Singh <[EMAIL PROTECTED]> a écrit :
[reordered]
> How about calling this one fill_threadgroup_stats()?
> How about we call function add_tsk_stats()?
> I still prefer braces around do <--> while, I think the code is easier
> to read with them.
> Could we
Sorry for the resend, this is the same version as few minutes ago, but
stgit 0.13 correctly handles the mail --auto flag (unlike stgit
0.12.1 :-( ) so all recipients are actually Cced.
--
Guillaume
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Place fields added in v6 at the end of the struct.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Michael Neuling <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <[EMAIL PROTECTED]>
Cc: O
fill_threadgroup_stats() may want to know if it is filling
TASKSTATS_CMD_ATTR_TGID or TASKSTATS_CMD_ATTR_PID stats, so give it this
information in the tg_stats boolean.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL
patch, fill_threadgroup_stats() must be called
after add_tsk_stats() as it may overwrite some stats.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <[EMAIL PROTECTED]>
Cc: Oleg Nesterov &l
All the specific taskstats fields should only be manipulated in
{add_tsk,fill_threadgroup}_stats().
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <[EMAIL PROTECTED]>
Cc: Oleg Ne
Split the extended accounting taskstats fields into the threadgroup specific
ones and the thread specific ones. This should have no effect on the execution.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
requesters (fill_pid(),
fill_tgid() and fill_tgid_exit()) should only call add_tsk_stats() and
fill_threadgroup_stats() to get the stats.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <
compatibility between taskstats v5/v6.
- split further by preparing the bacct/xacct before the main patch.
- some indentation fixes.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <[EMAIL
Split the basic accounting taskstats fields into the threadgroup specific ones
and the thread specific ones. This should have no effect on the execution.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
patch, fill_threadgroup_stats() must be called
after add_tsk_stats() as it may overwrite some stats.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <[EMAIL PROTECTED]>
Cc: Oleg Nesterov &l
Place fields added in v6 at the end of the struct.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Michael Neuling <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <[EMAIL PROTECTED]>
Cc: O
Split the extended accounting taskstats fields into the threadgroup specific
ones and the thread specific ones. This should have no effect on the execution.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
All the specific taskstats fields should only be manipulated in
{add_tsk,fill_threadgroup}_stats().
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <[EMAIL PROTECTED]>
Cc: Oleg Ne
compatibility between taskstats v5/v6.
- split further by preparing the bacct/xacct before the main patch.
- some indentation fixes.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <[EMAIL
fill_threadgroup_stats() may want to know if it is filling
TASKSTATS_CMD_ATTR_TGID or TASKSTATS_CMD_ATTR_PID stats, so give it this
information in the tg_stats boolean.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL
requesters (fill_pid(),
fill_tgid() and fill_tgid_exit()) should only call add_tsk_stats() and
fill_threadgroup_stats() to get the stats.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <
Split the basic accounting taskstats fields into the threadgroup specific ones
and the thread specific ones. This should have no effect on the execution.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
patch, fill_threadgroup() must be called after
add_tsk() as it may overwrite some stats.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <[EMAIL PROTECTED]>
Cc: Oleg Nesterov <[EMAIL PRO
fill_thread_group() may want to know if it is filling TASKSTATS_CMD_ATTR_TGID
or TASKSTATS_CMD_ATTR_PID stats, so give it this information in the tg_stats
boolean.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL
(fill_pid(), fill_tgid() and
fill_tgid_exit()) should only call add_tsk() and fill_threadgroup() to get the
stats.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc: Jonathan Lim <[EMAIL PROTECTED]>
C
p of fill_tgid_exit() by the way.
- bacct fields are also combined for all threads.
- Instead of assuming memory stats are identical for all threads, we
take the max of all threads.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan
Le Thu, 13 Sep 2007 16:41:41 +0400,
Oleg Nesterov <[EMAIL PROTECTED]> a écrit :
> (sorry, have no time to read the patch carefully, just a couple of
> minor random "unless I misread this patch" nits)
Thank you Oleg, hopefully I addressed all your comments in v4.
> > + do
> > + if (!t
way.
- bacct fields are also combined for all threads.
- Instead of assuming memory stats are identical for all threads, we
take the max of all threads.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTECTED]>
Cc: Jay Lan <[EMAIL PROTECTED]>
Cc
Le Fri, 7 Sep 2007 16:37:57 -0700 (PDT),
Jonathan Lim <[EMAIL PROTECTED]> a écrit :
> > Excellent, so can Guillaume change ac_btime to be just
> > tsk->start_time?
>
> I don't think so. Current time (xtime) is relative to the epoch;
> uptime and tsk->start_time (jiffies) are both relative to som
2007/9/7, Marco Berizzi <[EMAIL PROTECTED]>:
> Hello.
> Linux 2.6.23-rc5 after 30 minutes crash with this
> error message (taken from serial console):
Hi, this should be fixed in mainline by
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5c127c58ae9bf196d7878
ingh.
- Very light cleanup of fill_tgid_exit() by the way.
- bacct fields are also combined for all threads.
- Instead of assuming memory stats are identical for all threads, we
take the max of all threads.
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir Singh <[EMAIL PROTEC
Le Sun, 26 Aug 2007 10:28:44 +0530,
Balbir Singh <[EMAIL PROTECTED]> a écrit :
> From what I understand, task->start_time and task->real_start_time
> are taken from the realtime clock. The accounting in CSA seems
> to be very similar to the accounting done in do_acct_process()
> (kernel/acct.c).
>
Le Mon, 20 Aug 2007 22:31:08 +0530,
Balbir Singh <[EMAIL PROTECTED]> a écrit :
> > --- a/kernel/taskstats.cSat Aug 18 17:15:17 2007 -0700
> > +++ b/kernel/taskstats.cSun Aug 19 17:20:15 2007 +0200
> > @@ -246,6 +246,8 @@ static int fill_tgid(pid_t tgid, struct
> >
> > stats->
light cleanup of fill_tgid_exit() by the way.
- bacct fields are also combined for all threads.
- Instead of assuming memory stats are identical for all threads, we
take the max of all threads (hiwater_rss and hiwater_vm).
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
Cc: Balbir
==
Code: 8b 56 04 89 d8 e8 10 fb ff ff 85 ff 74 0d 8b 97 d0 00 00 00 89
d8 e8 9d ff ff ff 5b 5e 5f 5d c3 55 89 e5 57 56 53 89 c3 83 ec 04 <8b>
40 64 85 c0 89 45 f0 74 08 8d 43 10 e8 e0 ee 0b 00 8b 83 20
EIP: [] device_del+0xb/0x23a SS:ESP 0068:f594ef0c
Signed-off-by: Guillaume Chazar
85 ff 74 0d 8b 97 d0 00 00 00 89
d8 e8 9d ff ff ff 5b 5e 5f 5d c3 55 89 e5 57 56 53 89 c3 83 ec 04 <8b>
40 64 85 c0 89 45 f0 74 08 8d 43 10 e8 e0 ee 0b 00 8b 83 20
EIP: [] device_del+0xb/0x23a SS:ESP 0068:f594ef0c
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
diff -r 155
[Resent with different recipients as [EMAIL PROTECTED] bounced with
a User unknown]
Hi,
This patch adds all thread accounting stats for the global tgid stats.
As a shameless plug, this fixes iotop -P (http://guichaz.free.fr/misc/iotop.py).
Signed-off-by: Guillaume Chazarain <[EMAIL PROTEC
Hi,
This patch adds all thread accounting stats for the global tgid stats.
As a shameless plug, this fixes iotop -P (http://guichaz.free.fr/misc/iotop.py).
Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
---
diff -r 22708012ca6e kernel/taskstats.c
--- a/kernel/taskstats.cT
2007/8/2, Peter Zijlstra <[EMAIL PROTECTED]>:
> I think Dave's block_page_mkwrite() stuff addresses this as well, no?
>
> http://lkml.org/lkml/2007/3/18/198
I saw a similar problem some time ago with msync:
http://lkml.org/lkml/2006/12/29/136 but Andrew didn't
like my patch.
--
Guillaume
-
To u
> Comments anyone?
This is not specific to the kernel.
It was discussed here: http://lkml.org/lkml/2007/1/24/258
http://cyberelk.net/tim/portreserve/ seems to be the solution,
it's a pity it is not widely deployed.
Cheers.
--
Guillaume
-
To unsubscribe from this list: send the line "unsubscribe
2007/6/7, Guillaume Chazarain <[EMAIL PROTECTED]>:
Also, it sounds like a per-thread prctl, fun with syslets though ... ;-)
Oops, even if the user takes care to reset the prctl after his code (the
library problem), there are still signals that can run with an unexpected
prctl. Sorry f
2007/6/7, Linus Torvalds <[EMAIL PROTECTED]>:
syscall_indirect(unsigned long flags, sigset_t *,
int syscall, unsigned long args[6]);
Would that also be the user interface or all the wrappers would
still be implemented by the glibc?
Also, it sounds like a per-t
Hi all,
I am experiencing a buffer full condition on a pty, except that I use it with
O_NONBLOCK so I expect it to eat as much data as it can without overflowing.
Here is a simple testcase in Python, asyncore is Python's way to use select(2):
-8<-8<-8<-8<
Hi,
wait time is 90+% , which means that machine is waiting, rather than doing
something meanwhile. (I guess).
Yes, the machine spends its time waiting for the disk to do its things
as it does not have anything else to do. Nothing to worry about. If
you want, launch some CPU bound process at t
Srivatsa Vaddagiri a écrit :
Can you repeat your tests with this patch pls? With the patch applied, I am
now getting the same split between nice 0 and nice 10 task as CFS-v13
provides (90:10 as reported by top )
Yep, this fixes the problem for me too.
Thanks.
--
Guillaume
-
To unsubscribe fro
[EMAIL PROTECTED] a écrit :
block_write_full_page() forgot to propagate ENPSOC into the address_space.
--- a/fs/buffer.c~block_write_full_page-handle-enospc
+++ a/fs/buffer.c
@@ -1727,6 +1727,7 @@ recover:
} while ((bh = bh->b_this_page) != head);
SetPageError(page);
BU
2007/4/23, Ingo Molnar <[EMAIL PROTECTED]>:
p->wait_runtime >>= 1;
p_to->wait_runtime += p->wait_runtime;
I have no problem with clients giving some credit to X,
I am more concerned with X giving half of its credit to
a single client, a quarter of its credit to a
1 - 100 of 134 matches
Mail list logo
