elsa-user Mailing List for Enhanced Linux System Accounting (Page 3)
Brought to you by:
dionjp,
gthouvenin
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
(2) |
Apr
(3) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(4) |
2007 |
Jan
(3) |
Feb
(4) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(9) |
Oct
(11) |
Nov
(26) |
Dec
(24) |
2009 |
Jan
(9) |
Feb
(13) |
Mar
(16) |
Apr
(19) |
May
(34) |
Jun
(17) |
Jul
(32) |
Aug
(7) |
Sep
(4) |
Oct
|
Nov
|
Dec
(7) |
2010 |
Jan
(6) |
Feb
(4) |
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Guillaume T. <gui...@bu...> - 2005-03-25 13:13:18
|
Hello, Here is the new released 0.6 ChangeLog: We use the fork connect module to get information when the Linux kernel is forking. This fork connector is controlled by the new fcctl (fork connector controller). The Communication between jobd and kernel is done through the netlink interface. Communication between jobd and the user space application (elsa) is done through classical unix sockets. We improve the computation of the message's sequence number. All informations to download and install ELSA are available on the ELSA website. The scope has been updated. http://elsa.sourceforge.net Every comments, feedbacks and suggestions are welcome, The ELSA Team. |
From: Guillaume T. <gui...@bu...> - 2005-03-23 12:42:16
|
Hello, The fork connector is now enable (and disable) through the new fork connector controller. This application must be run as root. On the LKML and on the elsa-devel mailing list, the following problem was posted: "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? Shouldn't it turn off the fork-event notification when the number of listeners become zero?" One solution to solve this problem is to write a specialized controller utility that enable and disable the fork connector and also get its status. The ELSA scope has been updated to reflet the change. The application is available on the CVS or from the web page: http://cvs.sourceforge.net/viewcvs.py/elsa/elsa_project/utils/fcctl.c Regards, The ELSA team. |
From: Guillaume T. <gui...@bu...> - 2004-11-04 13:05:45
|
Hello, You will find first results on the following WEB page. It's a real example of what can be done. Code used to run the test is available via http://sourceforge.net/project/showfiles.php?group_id=105806&package_id=133206 Results can be view at: http://elsa.sourceforge.net/sample_session.html Every comments are welcome, Best regards, The ELSA Team |
From: Guillaume T. <gui...@bu...> - 2004-10-12 06:11:23
|
================================================= The User space Enhanced Linux System Accounting ================================================= A new ELSA version is available through the CVS http://cvs.sourceforge.net/viewcvs.py/elsa/elsa_project/ It's a complete new design that provides a solution with minimal modifications in the Linux kernel (only 4 lines in kernel/fork.c). According to the discussion on the lse-tech mailing-list, it appears that two steps (at least) are required to improve accounting. We need to improve accounting structure. The current BSD-accounting structure doesn't have enough informations. Metrics computed by ISA module can be added to BSD accounting. According to the other discussion (like Andi Kleen's comment about the patch I wrote when I wanted to add CSA IO values in the BSD accounting http://lkml.org/lkml/2004/8/2/70), the current method to get metrics about blocks/char read/write is not accurate since most writes can be accounted to pdflushd. We need to be able to manage groups of processes as it's clear that a major accounting improvement is the per-job accounting. I don't know if "job" is the right noun. There are several implementation that already exist and some of them are already in the kernel. The property needed here is that if a process is in a container, its children will be in the same container. Different implementations can be: - PAGG + JOB (job) - ELSA (bank) - CKRM (class) - CPUSET (a cpuset of all CPUs can act as a container) In this project we propose a user space solution for the enhanced accounting. Here is the User space Enhanced Linux System Accounting (ELSA) scope. ------------- ELSA scope ------------- Work can be split in the following parts : 1. A kernel patch 2. A kernel module 3. A user space daemon 4. Per-process accounting informations 5. A user space application 1. Kernel patch The kernel patch inserts a hook during the fork (in the do_fork() routine). The goal is to provide a solution to trace fork calls. This is the only modification done in the Linux vanilla tree and it adds 4 lines. We made some measures to evaluate the impact of those addition. We compiled a kernel and here are the results: we run a "make O=/home/devel/build/k2681 bzImage" on a Bi-Processor Intel(R) Xeon(TM) CPU 2.80GHz with 2Go of memory vanilla: real 6m11.292s user 5m34.802s sys 0m38.368s ELSA: kernel + patch The hook is added but the fork history module is not loaded real 6m11.485s user 5m34.268s sys 0m38.115s ELSA: kernel + patch + module The hook is added and the fork history module is loaded real 6m11.039s user 5m33.988s sys 0m38.221s ELSA: kernel + patch + module + daemon (doing nothing) The hook is added and the fork history module is loaded. A user space daemon runs but it doesn't perform any action. Thus, the fork signal handler is called but it does nothing. real 6m19.407s user 5m35.576s sys 0m37.188s ELSA: kernel + patch + module + daemon The hook is added and the fork history module is loaded. A user space daemon runs and it increments a counter to compute the number of forks. real 6m18.688s user 5m35.431s sys 0m37.572s As we can see, the impact is around 2% if you use a daemon and 0% if you don't use it. This patch is used by the kernel module. 2. Kernel module (fork_history.ko) This module is used as a fork events recorder. It uses the hook provided by the previous patch to be aware when a process is forking. It keeps this information and, if an application is registered, it sends a signal to inform that a fork occurred. The kernel module manages a device from which a user space daemon can register itself. This registration allows to know where to send the signal. Thus, the module provides ioctl routines to register or unregister an application. 3. User space daemon The user space daemon will register to the kernel module. Like this, it will be alerted when fork happens. With this information, it will be able to manage a groups of processes. It communicates to the high level application through message queue (IPC). Therefore, the high level application can send request to add or remove a process from a job (ie a groups of processes), it can also send a request to get information about current jobs. Thus, the daemon is under the high level application control. It has another task to accomplish. When it receives a signal from the fork history module, it will check if the process that has initiate the fork belongs to a job and if the answer is yes, the daemon will add the child into the same job. That's the main property of containers. 4. Per-process accounting informations This is not a part of ELSA but it is used by it. Per-process accounting information is provided by an extra mechanism like BSD accounting or CSA accounting. Discussions are opened about the per-process accounting and SGI people are making effort to add their accounting values in BSD process accounting. 5. User space application The user space application will use information provided by the user space daemon and the information provided by a per-process accounting mechanism (like BSD process accounting) to provide a per-group accounting information. It's also the interface for managing groups of processes. The current application (called elsa) is only here for testing. In the next version we want to provide a graphical tool to manage groups of processes. ------------------ General overview ------------------ KERNEL SPACE and | USER SPACE MODULE | | ------------------ | -------------------- | | /dev/fh | | | 2.Fork History |<------------| 3.Userspace Daemon | | Module | | | jobs manager | | |------------>| | ------------------ SIGRTFORK -------------------- ^ | ^ | | | | trace_fork() | | IPC ------------- | | ------>| 5.ELSA | -------------------- | | | | 1.Kernel PATCH | | | | | hook in do_fork() | | ------->| | -------------------- | | | | | | ------------- | | 4.Accounting Data ------------------- | All comments are welcome, The ELSA Team |
From: <ben...@id...> - 2004-05-25 08:31:08
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Jean-Pierre D. <jea...@bu...> - 2004-05-04 07:21:51
|
just testing, list seems not to work -- Jean-Pierre DION BT - Unix Competence Center Bull SA - Unix Projects Manager Tel : +33 (0)4 76 29 72 34, Fax : +33 (0)4 76 29 75 18 Mail : B1-204, Room : B1-228 http://www-frec.bull.com |