Martin Peschke wrote:
Jay Lan wrote:
Shailabh Nagar wrote:
Balbir Singh wrote:
Andrew,
The only other new set of patches to be discussed in this context
are the
statistics-infrastructure patches from Martin Peschke.
That infrastructure cannot meet the needs of delay accounting, CSA
etc. because
- it only provides "user pull" model of getting stats whereas
"kernel push" is
needed for delay accounting
Doesn't taskstats interface provide "user pull" request-reply model
also? Serious accounting needs to push accounting data as soon as
possible.
- it uses a relatively slow interface unsuitable for high volumes of
data.
By design.
I think it would be fatal to report every event relevant
to statistical data gathering up to user space. It's fine to have
the kernel maintain counters and to provide preprocessed data.
Given that, is there a need for a high-speed interface for a
huge amount of unprocessed statistical data?
Broadly speaking, yes. Inserting policy into the kernel will no doubt
save the data being sent to userspace but also
- limits flexibility of what userspace can do with it and
- adds to the kernel code base unnecessarily
Specifically for taskstats, there is a need for a high-speed interface
because of the potential volume of data resulting from
- large number of tasks in a single kernel
- high frequency of task exits
Some kernel-based preprocessing, such as per-tgid aggregation, can
help cut down the volume but as long as we have a need for getting per-task
data, an efficient interface will matter, atleast for our needs.
However, the user interface is a just one building brick,
which can be enhanced or replaced with moderate effort, if
there is a need.
True. This is not to suggest statistical infrastructure's interface
choice isn't correct..
just that its not enough for the needs we seek to serve.
A filesystem based interface has plenty of usability benefits so its
primarily a question
of which stats you want to export using its interface.
>> Each statistic has its own definition,
Allowing users to restrict accounting to what they need in their
particular case. Sensible defaults are usually available.
needs to be read separately using ASCII,
reading data continuously means open/read/close each time.....all of
which is not very conducive to large structures being sent to
userspace.
Debugfs file are fine for larger structures.
Unless one keeps reading statistics dozens of times per second,
I don't see an issue with that.
Since delay accounting stats can be exploited for resource management at
user
space, if one wants to get data for all tasks/processes periodically, it
could add up to a fairly
high demand for user<->kernel bandwidth even if the frequency need for
reading one task's
stats isn't that high. Its a question of scalability as number of tasks
increase.
For systemwide stats, your point is well taken...unlikely to be an
issue, unless of course, one
needs to read lots of them.
The question is: what are the requirements to be covered?
Yup...I think the infrastructures are serving differing needs.
Yes, i second the point. It won't be able to catch up the traffic.
- its oriented towards sampled data whereas taskstats isn't.
So, we have a good consensus from existing/potential users of
taskstats and would
very much appreciate it being included in 2.6.18.
Andrew, it has become clear that the community wants to see accounting
data processing being moved to userspace. Thus there is a need for a
common accounting interface to provide minimal works at kernel (via
hooks at fork and exit) and deliver data to userspace.
Both, the statistics infrastructure on behalf of its exploiters as well
as the exploiters of the taskstats interface do data preprocessing,
that is, maintain counters in the kernel.
User space counters won't perform, of course.
AFAICS, actual differences are:
- triggers for data delivery to user space
(statistics infrastructure: when user reads statistics through file,
taskstats: on certain task related events, right?)
Taskstats data delivery is triggered by
- user asking for data (i.e. akin to reading through a file, only done
through a command-response interface)
- on task exit event
- and, therewith, frequency of data delivery to user space
Martin
--Shailabh
-
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 FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
