3 ms·

Each log entry isn't necessarily written to disk one at a time. They will generally be buffered until enough have happened to need to flush. And they can be wri

by lambda 8y ago

Each log entry isn't necessarily written to disk one at a time. They will generally be buffered until enough have happened to need to flush. And they can be written compressed, and frequently have a lot of redundancy, so it can take a while before you accumulate enough data to need to flush to disk. And besides logging, there are things like nanosleep or spinlocks which may briefly spin while querying the time before yielding. I know of at least one CDN which was measurably impacted by the gettimeofday issue. And yes, you could have the access to the address itself be something you are given access to via a capability/handle, but then the system call itself (which is actually a vDSO call) wouldn't have to actually take a handle as a parameter.

naasking 8y ago
> And besides logging, there are things like nanosleep or spinlocks which may briefly spin while querying the time before yielding. Another poster said something similar, but using the clock for this seems strange to me. Yielding a time slice for a certain number of ticks doesn't need access to the current time. I have less objection to an ambient yield since that's really an operation on your own schedule capability. If you're after some kind of exponential backoff for a spinlock, that again doesn't seem to need the current time so much as a growing counter of the number of ticks to sleep. > And yes, you could have the access to the address itself be something you are given access to via a capability/handle, but then the system call itself (which is actually a vDSO call) wouldn't have to actually take a handle as a parameter. Correct, you'd use the handle to install an ambient clock in your environment. This leaves open the possibility that you can easily virtualize the clock by proxying the clock handle, ie. instead of the kernel updating your shared memory segment, it's another process. The point being that reifying everything as a handle makes arbitrary virtualization patterns possible, but having ambient authorities all the way down to root makes it much more difficult.
- hueving 8y ago
  >Another poster said something similar, but using the clock for this seems strange to me. Does it matter if it seems strange to you? The GP gave real world examples of where this is an impact. I'm not sure why you are arguing against the design.
  - naasking 8y ago
    > The GP gave real world examples of where this is an impact. I'm not sure why you are arguing against the design. Because the design is questionable, and so the example is questionable. Isn't that obvious? Why else would I bring it up?
- lambda 8y ago
  Yes, I agree that using the handle to install an ambient clock is probably better than just having one exist, for the reasons you cite.

by lambda 8y ago

naasking 8y ago

> And besides logging, there are things like nanosleep or spinlocks which may briefly spin while querying the time before yielding. Another poster said something similar, but using the clock for this seems strange to me. Yielding a time slice for a certain number of ticks doesn't need access to the current time. I have less objection to an ambient yield since that's really an operation on your own schedule capability. If you're after some kind of exponential backoff for a spinlock, that again doesn't seem to need the current time so much as a growing counter of the number of ticks to sleep. > And yes, you could have the access to the address itself be something you are given access to via a capability/handle, but then the system call itself (which is actually a vDSO call) wouldn't have to actually take a handle as a parameter. Correct, you'd use the handle to install an ambient clock in your environment. This leaves open the possibility that you can easily virtualize the clock by proxying the clock handle, ie. instead of the kernel updating your shared memory segment, it's another process. The point being that reifying everything as a handle makes arbitrary virtualization patterns possible, but having ambient authorities all the way down to root makes it much more difficult.

hueving 8y ago
>Another poster said something similar, but using the clock for this seems strange to me. Does it matter if it seems strange to you? The GP gave real world examples of where this is an impact. I'm not sure why you are arguing against the design.
- naasking 8y ago
  > The GP gave real world examples of where this is an impact. I'm not sure why you are arguing against the design. Because the design is questionable, and so the example is questionable. Isn't that obvious? Why else would I bring it up?
lambda 8y ago
Yes, I agree that using the handle to install an ambient clock is probably better than just having one exist, for the reasons you cite.