Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)

Peter Jeremy wrote:
SunOS 4 (not sure about SunOS 5) exports a per-CPU page that
includes a high-resolution timer amongst other things.

On Wed, 10 May 2006, David Xu wrote:
One of the problems to implement it is that atomic operations,
if there are multiple integer needs to be updated by kernel,
userland maybe gets an inconsistent result, the way to avoid the
problem is using two generation numbers.

A lot of the need for atomic operations goes away if the page (or
whatever) refers to the current CPU - the page is either being updated
by the current CPU in kernel mode or read by the current CPU in
userland. The page won't be updated/accessed by other CPUs. You
still need to update the base time and TSC (or whatever) count in a
way that looks atomic to userland but I suspect the kernel could
achieve this by twiddling the code transparently to userland (eg there
are two copies of the base/count and the kernel flips a pointer
between then).

On Wed, 2006-May-10 12:01:57 +0800, David Xu wrote:
Daniel Eischen wrote:
Can you not make a simple pseudo device driver and mmap the page?

mmap is fine if you don't care binary compatible, exporting a kernel
page which can be executed by userland is more flexible, kernel can
change it freely without having to change libc.

These aren't mutually exclusive - .so's are mmap'd. All libc needs
to do is mmap a page from a pseudo device and execute a function in
it. Either the function could be at a magic address or the pseudo
device could simulate a shared object so you just dlopen() the device.


How about making the scheduler insert the current time into something
resembling in functionality of a cpu local variable (register? cache
area?) whenever there is a context switch by the scheduler. Then
whenever you need the current time the userland application would read
it off this cpu local variable/holy area requiring no additional context
switch.

Or do the currently running (on that cpu) userland application require
the ability to read the current time more often than once per "time
slot"? Do i make sense?

*ducks for cover*

--
Sten Daniel Sørsdal

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Special schedulers, one CPU only kernel, one only userland
    ... Normally a second CPU ... > the routing daemon in userland. ... > forwarding in the kernel. ... > Hence my question to the SMP and scheduler gurus: ...
    (freebsd-arch)
  • ppc/ppc64 and x86 vsyscalls
    ... I've seen the various debates regarding the x86 vsyscalls. ... The idea is that the kernel already has the necessary infrastructure ... based on which CPU we are running on. ... at all) and possibly a userland implementation of gettimeofday. ...
    (Linux-Kernel)
  • Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)
    ... SunOS 4 exports a per-CPU page that ... if there are multiple integer needs to be updated by kernel, ... userland maybe gets an inconsistent result, ... whatever) refers to the current CPU - the page is either being updated ...
    (freebsd-current)
  • Re: IPFW & natd vs ipfilter & ipnat
    ... >Because of CPU or because of protocol? ... >> on NATed connections via ipnat vs. natd using DSL and PPPoE. ... be copied from kernel to userland and back again. ...
    (FreeBSD-Security)
  • Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)
    ... if there are multiple integer needs to be updated by kernel, ... userland maybe gets an inconsistent result, ... Another problem is how you tell userland the address of the kernel ...
    (freebsd-current)