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 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.
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 (task
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_stru
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.
>>
>>
lt;[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
rash.o] Error 1
> make: *** [arch/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
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;
>
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
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 pr
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 wrote:
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.
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
Evgeniy
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
cq
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 ot
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 more
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 fork_connecto
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 tu
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 applica
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
character-rea
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 discuss
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 was
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 the
ed by BSD/CSA.
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 the acct_process() call with a netlink.
If ELSA is to use the enhanced accounting data, it needs the CSA
eop handling
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
patch only 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
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
aggregatio
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 c
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
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:
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 var
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
ction' 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: lin
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
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 performanc
41 matches
Mail list logo