Vivek Goyal wrote:
> On Tue, Aug 21, 2007 at 06:18:31AM -0700, Jay Lan wrote:
> [..]
>>>>> Now user will be able to view all the die_chain users through sysfs and
>>>>> be able to modify the order in which these should run by modifying their
>>>>
Vivek Goyal wrote:
On Tue, Aug 21, 2007 at 06:18:31AM -0700, Jay Lan wrote:
[..]
Now user will be able to view all the die_chain users through sysfs and
be able to modify the order in which these should run by modifying their
priority. Hence all the RAS tools can co-exist.
This is my image
Vivek Goyal wrote:
> On Thu, Aug 16, 2007 at 06:26:35PM +0900, Takenori Nagano wrote:
>> Vivek Goyal wrote:
>> > So for the time being I think we can put RAS tools on die notifier list
>>> and if it runs into issues we can always think of creating a separate list.
>>>
>>> Few things come to mind.
Vivek Goyal wrote:
On Thu, Aug 16, 2007 at 06:26:35PM +0900, Takenori Nagano wrote:
Vivek Goyal wrote:
So for the time being I think we can put RAS tools on die notifier list
and if it runs into issues we can always think of creating a separate list.
Few things come to mind.
- Why there
Andrew Morton wrote:
> On Tue, 05 Jun 2007 14:43:50 + Maxim Uvarov <[EMAIL PROTECTED]> wrote:
>
>> Patch makes available to the user the following
>> task and process performance statistics:
>> * Involuntary Context Switches (task_struct->nivcsw)
>> * Voluntary Context Switches
Andrew Morton wrote:
On Tue, 05 Jun 2007 14:43:50 + Maxim Uvarov [EMAIL PROTECTED] wrote:
Patch makes available to the user the following
task and process performance statistics:
* Involuntary Context Switches (task_struct-nivcsw)
* Voluntary Context Switches
Andrew Morton wrote:
> On Wed, 30 May 2007 18:49:46 +
> Maxim Uvarov <[EMAIL PROTECTED]> wrote:
>
>> Removed syscall counters from patch.
>>
>>
>>
>>
>> Patch makes available to the user the following
>> task and process performance statistics:
>> * Involuntary Context Switches
Add Jonathan Lim to cc, who is working on CSA userland implementation
to use the taskstats data that this patch is going to remove.
Thanks,
- jay
Andrew Morton wrote:
> On Wed, 30 May 2007 18:49:46 +
> Maxim Uvarov <[EMAIL PROTECTED]> wrote:
>
>> Removed syscall counters from patch.
>>
Add Jonathan Lim to cc, who is working on CSA userland implementation
to use the taskstats data that this patch is going to remove.
Thanks,
- jay
Andrew Morton wrote:
On Wed, 30 May 2007 18:49:46 +
Maxim Uvarov [EMAIL PROTECTED] wrote:
Removed syscall counters from patch.
Patch
Andrew Morton wrote:
On Wed, 30 May 2007 18:49:46 +
Maxim Uvarov [EMAIL PROTECTED] wrote:
Removed syscall counters from patch.
Patch makes available to the user the following
task and process performance statistics:
* Involuntary Context Switches (task_struct-nivcsw)
*
r <[EMAIL PROTECTED]>
>>> I made a similar change when porting to xen, but I hadn't thought
>>> to see if mainline linux needs it to.
>>>
>>> Acked-by: Simon Horman <[EMAIL PROTECTED]>
>> I think there's an additional change needed. Without that, it
-by: Simon Horman [EMAIL PROTECTED]
I think there's an additional change needed. Without that, it leads to
a NULL pointer dereference.
Yep, it is needed. The missing line was in Jack's original patch
but was lost somehow in 2.6.20.
Acked-by: Jay Lan [EMAIL PROTECTED]
Maybe I should also get my
h/ia64/kernel] Error 2
>
> Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>
> ---
Looks good to me also.
Acked-by: Jay Lan <[EMAIL PROTECTED]>
> machine_kexec.c
> Applies on top of 2.6.20.
>
> arch/ia64/kernel/crash.c | 11 +++
> arch/ia64/kernel/
-by: Jay Lan [EMAIL PROTECTED]
machine_kexec.c
Applies on top of 2.6.20.
arch/ia64/kernel/crash.c | 11 +++
arch/ia64/kernel/machine_kexec.c |2 ++
2 files changed, 9 insertions(+), 4 deletions(-)
--- 0002/arch/ia64/kernel/crash.c
+++ work/arch/ia64/kernel/crash.c
Horms wrote:
> On Fri, Feb 02, 2007 at 11:01:21AM +0800, Zou, Nanhai wrote:
> void
> machine_crash_shutdown(struct pt_regs *pt)
> @@ -132,11 +134,12 @@ kdump_cpu_freeze(struct unw_frame_info *
> atomic_inc(_cpu_freezed);
> kdump_status[cpuid] = 1;
>
Horms wrote:
On Fri, Feb 02, 2007 at 11:01:21AM +0800, Zou, Nanhai wrote:
void
machine_crash_shutdown(struct pt_regs *pt)
@@ -132,11 +134,12 @@ kdump_cpu_freeze(struct unw_frame_info *
atomic_inc(kdump_cpu_freezed);
kdump_status[cpuid] = 1;
mb();
- if (cpuid == 0) {
Horms wrote:
> Hi,
>
> this patch fills in the portions for ia64 kexec.
>
> I'm actually not sure what options are required for the dump-capture
> kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
> Or more to the point, I'm not sure if irqpoll is needed or not.
>
> This
Horms wrote:
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires
Yes, our CSA customers reported same problem. CSA already incoporated
same fix to our kernel module code. :)
Cheers,
- jay
Peter Staubach wrote:
Hi.
There is a problem in the accounting subsystem in the kernel can not
correctly handle files larger than 2GB. The output file containing
the
Yes, our CSA customers reported same problem. CSA already incoporated
same fix to our kernel module code. :)
Cheers,
- jay
Peter Staubach wrote:
Hi.
There is a problem in the accounting subsystem in the kernel can not
correctly handle files larger than 2GB. The output file containing
the
the system
is running AIM7 and/or ubench.
The original fclisten.c and fork-test.c are attached for your reference.
- jay
Evgeniy Polyakov wrote:
On Fri, 08 Apr 2005 20:31:20 -0700
Jay Lan <[EMAIL PROTECTED]> wrote:
With the patch you provide to me, i did not see the bugcheck
at cn_queue_w
the system
is running AIM7 and/or ubench.
The original fclisten.c and fork-test.c are attached for your reference.
- jay
Evgeniy Polyakov wrote:
On Fri, 08 Apr 2005 20:31:20 -0700
Jay Lan [EMAIL PROTECTED] wrote:
With the patch you provide to me, i did not see the bugcheck
at cn_queue_wrapper
005 15:08:13 -0700
Jay Lan <[EMAIL PROTECTED]> wrote:
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
Ok.
The latest sources are always awailable at
http://tservice.net.ru/~s0mbre/archive/connector
- jay
Jay Lan wrot
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could
Lan [EMAIL PROTECTED] wrote:
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
Ok.
The latest sources are always awailable at
http://tservice.net.ru/~s0mbre/archive/connector
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1
rogram received 1824062 while expecting 1824061
it adjusted itself to expect the next one being 1824063. But instead
the message of 1824062 arrived the second time.
- jay
Jay Lan wrote:
Hi Evgeniy,
Should i be concerned about this bugcheck?
I have seen this happening a number of times, all with th
Hi Evgeniy,
Should i be concerned about this bugcheck?
I have seen this happening a number of times, all with the same signature
in my testing. I ran a mix of AIM7, ubench, fork-test (continuously
fork new
processes), and another program reading from the fork connector socket.
Thanks,
- jay
Hi Evgeniy,
Should i be concerned about this bugcheck?
I have seen this happening a number of times, all with the same signature
in my testing. I ran a mix of AIM7, ubench, fork-test (continuously
fork new
processes), and another program reading from the fork connector socket.
Thanks,
- jay
1824062 while expecting 1824061
it adjusted itself to expect the next one being 1824063. But instead
the message of 1824062 arrived the second time.
- jay
Jay Lan wrote:
Hi Evgeniy,
Should i be concerned about this bugcheck?
I have seen this happening a number of times, all with the same
Andrew Morton wrote:
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
This patch adds a fork connector in the do_fork() routine.
...
The fork connector is used by the Enhanced Linux System Accounting
project http://elsa.sourceforge.net
Does it also meet all the in-kernel requirements for
Andrew Morton wrote:
Guillaume Thouvenin [EMAIL PROTECTED] wrote:
This patch adds a fork connector in the do_fork() routine.
...
The fork connector is used by the Enhanced Linux System Accounting
project http://elsa.sourceforge.net
Does it also meet all the in-kernel requirements for
The parent information ((ppid,pid) pair) is useful for process group
aggregation while do_exit() hook is needed to save per task
accounting data before the task data is disposed.
Thanks,
- jay
dean gaudet wrote:
On Tue, 29 Mar 2005, Jay Lan wrote:
The fork_connector is not designed to solve
The parent information ((ppid,pid) pair) is useful for process group
aggregation while do_exit() hook is needed to save per task
accounting data before the task data is disposed.
Thanks,
- jay
dean gaudet wrote:
On Tue, 29 Mar 2005, Jay Lan wrote:
The fork_connector is not designed to solve
Paul,
The fork_connector is not designed to solve accounting data collection
problem.
The accounting data collection must be done via a hook from do_exit().
The acct_process() hook invokes do_acct_process() to write BSD
accounting data to disk. CSA needs a similar hook off do_exit() to
collect
Paul Jackson wrote:
Guillaume wrote:
The goal of the fork connector is to inform a user space application
that a fork occurs in the kernel. This information (cpu ID, parent PID
and child PID) can be used by several user space applications. It's not
only for accounting. Accounting and
Paul Jackson wrote:
Guillaume wrote:
The goal of the fork connector is to inform a user space application
that a fork occurs in the kernel. This information (cpu ID, parent PID
and child PID) can be used by several user space applications. It's not
only for accounting. Accounting and
Paul,
The fork_connector is not designed to solve accounting data collection
problem.
The accounting data collection must be done via a hook from do_exit().
The acct_process() hook invokes do_acct_process() to write BSD
accounting data to disk. CSA needs a similar hook off do_exit() to
collect
Evgeniy Polyakov wrote:
On Tue, 22 Mar 2005 10:26:19 -0800
Ram <[EMAIL PROTECTED]> wrote:
On Mon, 2005-03-21 at 23:07, Guillaume Thouvenin wrote:
On Mon, 2005-03-21 at 12:52 -0800, Ram wrote:
If a bunch of applications are listening for fork events,
your patch allows any application to
Ram wrote:
On Tue, 2005-03-22 at 11:22, Evgeniy Polyakov wrote:
On Tue, 22 Mar 2005 10:26:19 -0800
Ram <[EMAIL PROTECTED]> wrote:
On Mon, 2005-03-21 at 23:07, Guillaume Thouvenin wrote:
On Mon, 2005-03-21 at 12:52 -0800, Ram wrote:
If a bunch of applications are listening for fork events,
Guillaume Thouvenin wrote:
On Mon, 2005-03-21 at 12:52 -0800, Ram wrote:
If a bunch of applications are listening for fork events,
your patch allows any application to turn off the
fork event notification? Is this the right behavior?
Yes it is. The main management is done by
Guillaume Thouvenin wrote:
On Mon, 2005-03-21 at 12:52 -0800, Ram wrote:
If a bunch of applications are listening for fork events,
your patch allows any application to turn off the
fork event notification? Is this the right behavior?
Yes it is. The main management is done by
Evgeniy Polyakov wrote:
On Tue, 22 Mar 2005 10:26:19 -0800
Ram [EMAIL PROTECTED] wrote:
On Mon, 2005-03-21 at 23:07, Guillaume Thouvenin wrote:
On Mon, 2005-03-21 at 12:52 -0800, Ram wrote:
If a bunch of applications are listening for fork events,
your patch allows any application to
I thought you planned to read from CSA pacct file?
Well, while we are in discussion of whether to merge and
replace BSD accounting with CSA accounting, your proposed
change will provide you data on charater I/O in a BSD pacct
file. I supposed you do not need to have seperate fields on
I thought you planned to read from CSA pacct file?
Well, while we are in discussion of whether to merge and
replace BSD accounting with CSA accounting, your proposed
change will provide you data on charater I/O in a BSD pacct
file. I supposed you do not need to have seperate fields on
The patch i propose is tiny, simple and straight forward. It
touches only one file and leaves the CSA code in a configurable
loadable module. It broke nobody's code and it does not need to
redesign existing BSD kernel code and utilities.
If we are to merge the code, there are some detailed
The patch i propose is tiny, simple and straight forward. It
touches only one file and leaves the CSA code in a configurable
loadable module. It broke nobody's code and it does not need to
redesign existing BSD kernel code and utilities.
If we are to merge the code, there are some detailed
one.
- jay
Guillaume Thouvenin wrote:
On Tue, 2005-03-01 at 10:06 -0800, Jay Lan wrote:
Sorry I was not clear on my point.
I was trying to point out that, an exit hook for BSD and CSA is
essential to save accounting data before the data is gone. That
can not be done with a netlink.
So, my patch
one.
- jay
Guillaume Thouvenin wrote:
On Tue, 2005-03-01 at 10:06 -0800, Jay Lan wrote:
Sorry I was not clear on my point.
I was trying to point out that, an exit hook for BSD and CSA is
essential to save accounting data before the data is gone. That
can not be done with a netlink.
So, my patch
and call do_acct_process
for BSD.
Thanks,
- jay
Guillaume Thouvenin wrote:
On Mon, 2005-02-28 at 10:56 -0800, Jay Lan wrote:
The exit hook is essential for CSA to save off data before the data
is gone, A netlink type of thing does not help. BSD is in the same
situation. You can not replace
and call do_acct_process
for BSD.
Thanks,
- jay
Guillaume Thouvenin wrote:
On Mon, 2005-02-28 at 10:56 -0800, Jay Lan wrote:
The exit hook is essential for CSA to save off data before the data
is gone, A netlink type of thing does not help. BSD is in the same
situation. You can not replace
ssential for CSA to save off data before the data
is gone, A netlink type of thing does not help. BSD is in the same
situation. You can not replace the acct_process() call with a netlink.
If ELSA is to use the enhanced accounting data, it needs the CSA
eop handling at exit as well.
Thanks,
- jay
the acct_process() call with a netlink.
If ELSA is to use the enhanced accounting data, it needs the CSA
eop handling at exit as well.
Thanks,
- jay
Guillaume Thouvenin wrote:
On Thu, 2005-02-24 at 20:46 -0800, Andrew Morton wrote:
Jay Lan [EMAIL PROTECTED] wrote:
Since my idea of providing an accounting
Andrew Morton wrote:
Jay Lan <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
> Kaigai Kohei <[EMAIL PROTECTED]> wrote:
>
>>In my understanding, what Andrew Morton said is "If target functionality can
>> implement in user space only, then we should not modify t
Chris Wright wrote:
* Jay Lan ([EMAIL PROTECTED]) wrote:
Andrew Morton wrote:
Kaigai Kohei <[EMAIL PROTECTED]> wrote:
In my understanding, what Andrew Morton said is "If target functionality
can
implement in user space only, then we should not modify the kernel-tree".
for
Andrew Morton wrote:
Kaigai Kohei <[EMAIL PROTECTED]> wrote:
In my understanding, what Andrew Morton said is "If target functionality can
implement in user space only, then we should not modify the kernel-tree".
fork, exec and exit upcalls sound pretty good to me. As long as
a) they use the same
Andrew Morton wrote:
Kaigai Kohei [EMAIL PROTECTED] wrote:
In my understanding, what Andrew Morton said is If target functionality can
implement in user space only, then we should not modify the kernel-tree.
fork, exec and exit upcalls sound pretty good to me. As long as
a) they use the same
Chris Wright wrote:
* Jay Lan ([EMAIL PROTECTED]) wrote:
Andrew Morton wrote:
Kaigai Kohei [EMAIL PROTECTED] wrote:
In my understanding, what Andrew Morton said is If target functionality
can
implement in user space only, then we should not modify the kernel-tree.
fork, exec and exit upcalls
Andrew Morton wrote:
Jay Lan [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Kaigai Kohei [EMAIL PROTECTED] wrote:
In my understanding, what Andrew Morton said is If target functionality can
implement in user space only, then we should not modify the kernel-tree.
fork, exec and exit upcalls
touchs one file: kernel/acct.c.
Signed-off-by: Jay Lan <[EMAIL PROTECTED]>
Index: linux/kernel/acct.c
===
--- linux.orig/kernel/acct.c2005-02-24 15:55:05.519092861 -0800
+++ linux/kernel/acct.c 2005-02-24 16:33:56.381584083
Tim Schmielau wrote:
On Tue, 22 Feb 2005, Andrew Morton wrote:
We really want to avoid doing such stuff in-kernel if at all possible, of
course.
Is it not possible to implement the fork/exec/exit notifications to
userspace so that a daemon can track the process relationships and perform
Tim Schmielau wrote:
On Tue, 22 Feb 2005, Andrew Morton wrote:
We really want to avoid doing such stuff in-kernel if at all possible, of
course.
Is it not possible to implement the fork/exec/exit notifications to
userspace so that a daemon can track the process relationships and perform
touchs one file: kernel/acct.c.
Signed-off-by: Jay Lan [EMAIL PROTECTED]
Index: linux/kernel/acct.c
===
--- linux.orig/kernel/acct.c2005-02-24 15:55:05.519092861 -0800
+++ linux/kernel/acct.c 2005-02-24 16:33:56.381584083 -0800
@@ -73,6
Hi Paul,
I think the microbenchmarking your link provides is irrelevant.
Your link provides benchmarking of doing a fork.
However, we are talking about inserting a callback routine
in a fork and/or an exit. The overhead is a function
call and time spent in the routine. The callback routine
can be
Kaigai Kohei wrote:
Hi, Thanks for your comments.
>> I think there are two issues about system accounting framework.
>>
>> Issue: 1) How to define the appropriate unit for accounting ?
>> Current BSD-accountiong make a collection per process accounting
>> information.
>> CSA make
Guillaume Thouvenin wrote:
On Tue, 2005-02-22 at 23:20 -0800, Andrew Morton wrote:
Kaigai Kohei <[EMAIL PROTECTED]> wrote:
The common agreement for the method of dealing with process aggregation
has not been constructed yet, I understood. And, we will not able to
integrate each process aggregation
Guillaume Thouvenin wrote:
On Tue, 2005-02-22 at 23:20 -0800, Andrew Morton wrote:
Kaigai Kohei [EMAIL PROTECTED] wrote:
The common agreement for the method of dealing with process aggregation
has not been constructed yet, I understood. And, we will not able to
integrate each process aggregation
Kaigai Kohei wrote:
Hi, Thanks for your comments.
I think there are two issues about system accounting framework.
Issue: 1) How to define the appropriate unit for accounting ?
Current BSD-accountiong make a collection per process accounting
information.
CSA make additionally a
Hi Paul,
I think the microbenchmarking your link provides is irrelevant.
Your link provides benchmarking of doing a fork.
However, we are talking about inserting a callback routine
in a fork and/or an exit. The overhead is a function
call and time spent in the routine. The callback routine
can be
Kaigai Kohei wrote:
Hello, everyone.
Andrew Morton wrote:
> Jay Lan <[EMAIL PROTECTED]> wrote:
>
>>Since the need of Linux system accounting has gone beyond what BSD
>>accounting provides, i think it is a good idea to create a thin layer
>>of common code f
Guillaume Thouvenin wrote:
On Fri, 2005-02-18 at 17:16 -0800, Andrew Morton wrote:
Jay Lan <[EMAIL PROTECTED]> wrote:
Since the need of Linux system accounting has gone beyond what BSD
accounting provides, i think it is a good idea to create a thin layer
of common code for various acco
Guillaume Thouvenin wrote:
On Fri, 2005-02-18 at 17:16 -0800, Andrew Morton wrote:
Jay Lan [EMAIL PROTECTED] wrote:
Since the need of Linux system accounting has gone beyond what BSD
accounting provides, i think it is a good idea to create a thin layer
of common code for various accounting
Kaigai Kohei wrote:
Hello, everyone.
Andrew Morton wrote:
Jay Lan [EMAIL PROTECTED] wrote:
Since the need of Linux system accounting has gone beyond what BSD
accounting provides, i think it is a good idea to create a thin layer
of common code for various accounting packages, such as BSD
' routines have been moved from
acct.c to acct_common.c. Files used to #include were
modified to #include .
This patch was generated against 2.6.11-rc3-mm2.
Signed-off-by: Jay Lan <[EMAIL PROTECTED]>
Index: linux/kernel/
accounting fields. Specifically, the tsk->acct_stimexpd
needs to be initialized to tsk->stime.
I have discussed this with Christoph Lameter and he gave me full
blessings to bring the calls back.
This initialize_acct_integrals patch was generated against
2.6.11-rc3-mm2 to fix the problem. Thanks!
Si
. Specifically, the tsk-acct_stimexpd
needs to be initialized to tsk-stime.
I have discussed this with Christoph Lameter and he gave me full
blessings to bring the calls back.
This initialize_acct_integrals patch was generated against
2.6.11-rc3-mm2 to fix the problem. Thanks!
Signed-off-by: Jay Lan
' routines have been moved from
acct.c to acct_common.c. Files used to #include linux/acct.h were
modified to #include linux/acct_common.h.
This patch was generated against 2.6.11-rc3-mm2.
Signed-off-by: Jay Lan [EMAIL PROTECTED]
Index: linux/kernel/fork.c
Andrew Morton wrote:
Christoph Lameter <[EMAIL PROTECTED]> wrote:
I hope that Roland's changes for higher resolution of cputime would
make that possible. But this is Jay's thing not mine. I just want to make
sure that the CSA patches does not get in the way of our attempts to
improve the
Andrew Morton wrote:
Christoph Lameter [EMAIL PROTECTED] wrote:
I hope that Roland's changes for higher resolution of cputime would
make that possible. But this is Jay's thing not mine. I just want to make
sure that the CSA patches does not get in the way of our attempts to
improve the performance
81 matches
Mail list logo
