a129a83c45
1998-07-21 Martin Baulig <martin@home-of-linux.org> * table.sgml: New file - basic documentation for the table () system call.
162 lines
5.9 KiB
Plaintext
162 lines
5.9 KiB
Plaintext
Path: news.uni-stuttgart.de!fu-berlin.de!taurus.uni-trier.DE!baulig
|
|
From: Martin Baulig <baulig@merkur.uni-trier.de>
|
|
Newsgroups: comp.os.linux.development.system
|
|
Subject: RFC: New system call for /proc information ?
|
|
Date: 07 Jun 1998 20:22:47 +0200
|
|
Lines: 143
|
|
Sender: baulig@Taurus.uni-trier.de
|
|
Message-ID: <of7zpfprs08.fsf@Taurus.uni-trier.de>
|
|
NNTP-Posting-Host: taurus.uni-trier.de (136.199.14.201)
|
|
Mime-Version: 1.0
|
|
Content-Type: text/plain; charset=iso-8859-1
|
|
Content-Transfer-Encoding: 8bit
|
|
NNTP-Posting-User: baulig
|
|
X-Access: 16 1542 1543
|
|
X-Trace: fu-berlin.de 897243777 29527 baulig 136.199.14.201
|
|
X-Newsreader: Gnus v5.6.11/XEmacs 20.3 - "Vatican City"
|
|
Xref: news.uni-stuttgart.de comp.os.linux.development.system:73539
|
|
|
|
[Posted to the Gnome Mailing List and to comp.os.linux.development.system]
|
|
|
|
Request for Comments:
|
|
====================
|
|
|
|
Should we have a new system call under Linux which fetches information
|
|
from the /proc filesytem similar to the table() function of DEC OSF/1 ?
|
|
|
|
The whole story:
|
|
===============
|
|
|
|
I am currently working on libgtop, a library that fetches information
|
|
from the proc filesystem for user processes. This library uses a suid
|
|
server on system where this is required. On Linux, the information are
|
|
fetched directly from the proc filesystem.
|
|
|
|
Now, I made some profilings (fetches 50000 times cpu, memory, swap,
|
|
uptime and loadavg):
|
|
|
|
Each sample counts as 0.01 seconds.
|
|
% cumulative self self total
|
|
time seconds seconds calls ns/call ns/call name
|
|
91.86 348.03 348.03 read
|
|
3.07 359.67 11.64 open
|
|
0.67 362.22 2.55 close
|
|
0.16 363.55 0.62 memset
|
|
0.16 364.14 0.59 __ipc
|
|
0.03 368.84 0.12 vsscanf (iovsscanf.c:31)
|
|
0.01 374.49 0.05 sscanf (sscanf.c:28)
|
|
0.00 378.71 0.01 semctl (semctl.c:32)
|
|
0.00 378.73 0.01 shmctl (shmctl.c:30)
|
|
|
|
granularity: each sample hit covers 4 byte(s) for 0.00% of 378.88 seconds
|
|
|
|
index % time self children called name
|
|
[1] 91.9 348.03 0.00 read [1]
|
|
-----------------------------------------------
|
|
[2] 3.1 11.64 0.00 open [2]
|
|
-----------------------------------------------
|
|
[3] 0.7 2.55 0.00 close [3]
|
|
-----------------------------------------------
|
|
[5] 0.2 0.62 0.00 memset [5]
|
|
-----------------------------------------------
|
|
[6] 0.2 0.59 0.00 __ipc [6]
|
|
-----------------------------------------------
|
|
[35] 0.0 0.12 0.00 vsscanf (iovsscanf.c:31) [35]
|
|
-----------------------------------------------
|
|
[96] 0.0 0.05 0.00 sscanf (sscanf.c:28) [96]
|
|
-----------------------------------------------
|
|
|
|
You see, it spends a lot of time in read() which is only used to read the
|
|
data from the files in /proc. Well, basically one can say that these
|
|
timings are not so bad, normally a process periodically fetches those
|
|
information say 10 times a seconds which makes 36000 invocations per
|
|
hour.
|
|
|
|
This will make a total of about 250 seconds per hour or on even say:
|
|
|
|
``a program fetching those information at a frequency of 10 will take
|
|
about 7 % of each hour just for reading files from /proc''.
|
|
|
|
Now look at timings of __ipc, they're about 350 times better 'cause this
|
|
is done using system calls.
|
|
|
|
So far so good, now look at how this is done on the DEC OSF/1 port of the
|
|
library (the following code is part of libgtop - GPL/LGPL):
|
|
|
|
CPU usage:
|
|
{
|
|
struct tbl_sysinfo sysinfo;
|
|
int ret;
|
|
|
|
ret = table (TBL_SYSINFO, 0, (char *) &sysinfo, 1,
|
|
sizeof (struct tbl_sysinfo));
|
|
|
|
buf->user = sysinfo.si_user;
|
|
buf->nice = sysinfo.si_nice;
|
|
buf->sys = sysinfo.si_sys;
|
|
buf->idle = sysinfo.si_idle;
|
|
}
|
|
|
|
Well, the table() command of DEC OSF/1 has may disadvantages, too - such
|
|
as requiring to be root to fetch any information about processes (well, for
|
|
each process that is not the current one).
|
|
|
|
But this works using system calls rather that reading and parsing files
|
|
and should be about as fast as getting the IPC information on Linux.
|
|
|
|
Under Linux, the current trend seems to be to move anything into the /proc
|
|
filesystem, but if you look at the timings, wouldn't it be better to also
|
|
implement a system call interface ?
|
|
|
|
Don't understand me wrong:
|
|
=========================
|
|
|
|
I *do not want* to *replace* the /proc filesystem - it's an excellent
|
|
idea to be able to fetch all information on the command line without
|
|
any program just a simple 'cat' - I want to *add* a *new* system call
|
|
to allow programmers to fetch those information faster that reading
|
|
from /proc.
|
|
|
|
To come to the point:
|
|
=====================
|
|
|
|
Is there any public interest in having a new system call under Linux
|
|
which can be used to fetch all information that are currently in the
|
|
/proc filesystem.
|
|
|
|
Basically, this system would be defined like this:
|
|
|
|
asmlinkage int
|
|
sys_table (int command, struct sysinfo_table *buf)
|
|
|
|
and be invoked like this:
|
|
|
|
#include <sys/table.h>
|
|
|
|
{
|
|
struct sysinfo_cpu cpu;
|
|
struct sysinfo_mem mem;
|
|
|
|
ret = table (TABLE_CPU, &cpu);
|
|
if (ret == -1) return; /* or invoke any error handler */
|
|
|
|
ret = table (TABLE_MEM, &mem);
|
|
if (ret == -1) return;
|
|
}
|
|
|
|
What do you think, folks. Should we have such a system call under Linux ?
|
|
I can do the implementation of this system call, but I want to have some
|
|
feedback first.
|
|
|
|
Martin
|
|
|
|
--
|
|
-----------------------------------------------------------------
|
|
Martin Baulig - Angewandte Mathematik - Universitaet Trier
|
|
|
|
baulig@castor.uni-trier.de, http://www.home-of-linux.com/
|
|
Key: 1024-bit key with ID C8178435 created 1997/01/24
|
|
ID: 67 C1 84 A0 47 F5 11 C5 5F 68 4C 84 99 05 C3 92
|
|
Finger me for public key or fetch finger.txt from the url above
|
|
------------------------------------------------------------------
|