Re: [TOMOYO #12 (2.6.28-rc2-mm1) 05/11] Memory and pathname management functions.

On Tue, 11 Nov 2008 15:34:39 +0900 Kentaro Takeda <takedakn@xxxxxxxxxxxxx> wrote:

Andrew Morton wrote:
Note that I said "kmalloc", not "kzalloc". This function zeroes
everything all the time, and surely that is not necessary. It's just a
waste of CPU time.

Callers of tmy_alloc assume that allocated memory is zeroed.

That isn't the point. For programmer convenience we could make
__alloc_pages() and kmalloc() zero all the memory too. But we don't
because it is slow.
Are you saying "make the callers of tmy_alloc() tolerable with
uninitialized memory"?

Well. That would be a desirable objective. I can understand the
reasons for taking the easy way out. Given that Tomoyo doesn't seem to
ever free memory again, one hopes that this function doesn't get called
a lot, so the performance impact of zeroing out all that memory should
be negligible.

I think. Maybe I misinterpreted tmy_alloc(), and perhaps it _is_
called frequently?

Creating pseudo files for each variables is fine, though I don't see
advantage by changing from
"echo Shared: 16777216 > /sys/kernel/security/tomoyo/meminfo" to
"echo 16777216 > /sys/kernel/security/tomoyo/quota/shared_memory".

Well for starters, the existing interface is ugly as sin and will make
kernel developers unhappy.

There is a pretty strict one-value-per-file rule in sysfs files, and
"multiple tagged values in one file" violates that a lot.
/sys/kernel/security/ is not sysfs but securityfs.
Does "one-value-per-file rule" also apply to securityfs?

It should apply. It's not so much a matter of rules and regulations.
One needs to look at the underlying _reasons_ why those rules came
about. We got ourselves into a sticky mess with procfs with all sorts
of ad-hoc data presentation and input formatting. It's inconsistent,
complex, makes tool writing harder, etc.

So we recognised our mistakes and when sysfs (otherwise known as procfs
V2 :)) came about we decided that sysfs files should not make the same
mistakes.

So, logically, that thinking should apply to all new pseudo-fs files.
Even, in fact, ones which are in /proc!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [TOMOYO #12 (2.6.28-rc2-mm1) 05/11] Memory and pathname management functions.
    ... waste of CPU time. ... For programmer convenience we could make ... __alloc_pagesand kmalloczero all the memory too. ... There is a pretty strict one-value-per-file rule in sysfs files, ...
    (Linux-Kernel)
  • Re: looking for a simple profiling idea
    ... That will let you see which are using the most CPU time. ... for a page of memory to be brought in from virtual memory on disk - it isn't doing anything at all. ... the iostat tool will give you a system-level picture of how much time is being spent waiting for IO. ...
    (comp.lang.java.programmer)
  • Re: whaich Hardware to speed up WOW
    ... image name, username, cpu, cpu time, mem usage, vm size ... when it comes to memory usage, it's the sum of both that counts ... ... because this is actually a pretty weird ammount, my notebook (1.5g with separate graphics memory) shows 1571760, a desktop machine here shows 1047276 ... ...
    (alt.games.warcraft)
  • Re: SMP LAPACK
    ... Shared Memory Parallel Architecture. ... Threads Speedup ... CPU Time in User Mode: ... CPU Time in Kernel Mode: ...
    (sci.math.num-analysis)
  • Re: Is Windows 98 SE More Secure Than OS X?
    ... It's so sad to see people so brainwashed by one company. ... ZERO CPU time and very little memory. ... Is it a waste of power to post on USENET all damn day? ...
    (comp.sys.mac.advocacy)