Re: [PATCH 4/5] Add a sysconf syscall

[Andy Lutomirski]

On 05/14/2011 12:34 PM, Andi Kleen wrote:
> > What glibc does (opening /proc/stat) is rather stupid, but i think your syscall
>
> I don't think it has any other choice today. So if anything is "stupid"
> it is the kernel for not providing efficient interfaces for this.
>
> > Note that these are mostly constant or semi-constant values that are updated
> > very rarely:
>
> That's not true. Most of them are dynamic. Take a look at the patch.
> Also several of those have changed recently.
>
> > If glibc is stupid and reads /proc/stat to receive something it could cache or
> > mmap() itself then hey, did you consider fixing glibc or creating a sane libc?
> Caching doesn't help when you have a workload that exec()s a lot.
> Also some of these values can change at runtime.
>
> > If we *really* want to offer kernel help for these values even then your
> > solution is still wrong: then the proper solution would be to define a standard
> > *data* structure and map it as a vsyscall *data* page - essentially a
> > kernel-guaranteed data mmap(), with no extra syscall needed!
>
> That's quite complicted because several of those are dynamically computed
> based on other values. Sometimes they are also not tied to the mm_struct -- like
> the vsyscall is. For example some of the rlimits are per task, not VM.
> Basically your proposal doesn't interact well with clone().
>
> Even if we ignored that semantic problem it would need another writable page
> per task because the values cannot be shared.
>
> Also I never liked the idea of having more writable pages per task,
> It increases the memory footprint of a single process more. Given a 4K
> page is not a lot, but lots of 4K pages add up. Some workloads like
> to have lots of small processes and I think that's a valuable use
> case Linux should stay lean and efficient at.
>
> [OK in theory one could do COW for the page and share it but that would
> get really complicated]
>
> I also don't think it's THAT performance critical to justify the vsyscall.
> The simple syscall is already orders of magnitude faster than /proc, and
> seems to solve the performance problems we've seen completely.
>
> It's also simple and straight forward and simple to userstand and maintain.
> I doubt any of that would apply to a vsyscall solution.
>
> I don't think the additional effort for a vsyscall would be worth
> it at this point, unless there's some concrete example that would
> justify it. Even then it wouldn't work for some of the values.

You could also add a vsyscall function and have that function pull the 
values from vvar data.  It would be very fast (i.e. almost as fast as 
mmaping some data) and it would be more portable.

If you built it on top of the vdso cleanup in my rdtsc patches, it would 
be dead simple, too.  (Think three or four lines of code and no linker 
hackery).

> Also a vsyscall doesn't help on non x86 anyways.

Add one?  x86-32 at least would benefit a lot.  (I'm not volunteering 
right now...)

--Andy
--
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/