Converting pointer to vm_offset_t
Hi all, Is there a way to convert a (char *) pointer (or in general any pointer) to a vm_offset_t type? I was thinking of sbuf_copyin, but I'm dealing with a process different from current in kernel. I want to copy the pointer to kernel space using a struct uio. Thanks in advance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] RUSAGE_THREAD
On 05/05/10 01:24, Kostik Belousov wrote:
On Wed, May 05, 2010 at 12:48:53AM +, Alexander Krizhanovsky wrote:
Konstantin,
Concerning i/o counters we collect them in rucollect() in for loop and
update in various places, for example in vfs_bio.c. Rusage of an exiting
threads is handled in exit1() - ruadd().
Your version of the patch certainly is more robust, however I'm still
concerning about following things, which could be done better:
1) Zeroing of thread runtime statistic looks fine if we use it only for
whole process statistic calculating, but now (when it's also used as is
for the thread statistic) it should be handled independently, i.e.
RUSAGE_{SELF,CHILDREN} calls should not affect the thread structures
somehow. So I suppose we need to introduce some new counters to proc
structure and counters update code (it was stopped me to go on this way).
What do you mean by zeroing of thread runtime statistic ? Can you, please,
point me to exact location in code ? I did not found such code when
I did initial review of your patch.
I did testing by repeatedly calling getrusage with alternated
RUSAGE_SELF/RUSAGE_THREAD commands, and got sane increasing snapshots
of statistic.
I meant zeroing of per-thread statistic in ruxagg() after updating of
the whole process time counters.
2) With first in mind, getruasge(RUSAGE_THREAD) is called in current
thread and doesn't affect or use information from other threads, so it
definitely should use less number of locks, may be with atomic
operations for read-update-write operations. In fact the same getting
per-thread statistic in Linux is done _without_ locks at all (however
Linux uses different process/thread model).
thread_lock() is spinlock, and it disables preemption. calcru1() is
very sensible to have ticks counters to be in consistent state.
You can look at kern_time.c implementation of CLOCK_THREAD_CPUTIME_ID,
where indeed only preepmtion is disabled by use of critical section.
On the other hand, td_rux is accessed by other threads, and caclru1()
updates should be properly syncronized. Since thread_lock would
be needed for this, and it would give slightly more consistent results
for the copy of td_ru, I used it.
I do not think that thread_lock for running thread is a bottleneck,
and getrusage definitely should be not a contention point for properly
written application.
Yes, you're right - if we wish to have lockless thread accounting, then
we need to redesign the whole rusage accounting, so I'm voting for
commit of the patch.
Indeed, I concerned more about PROC_LOCK/PROC_SLOCK - they are acquired
both in kern_getrusage() and could be a problem in multithreaded process
with intensive performance accounting in threads. This happens for
example in resource accounting systems for shared hosting which are
solved by custom extensions of Apache, MySQL and other servers.
If we're in time and it really looks like a problem (is getrusage() ever
a hotspot?) I can try to prepare the patch with less locking on this
weekend.
Also I still don't understand the sanity check in calccru1() for
negativeness of tu ( (int64_t)tu 0 ) - is it reachable? It seems that
it is possible only after about 300 thousand years of uptime... Could
you please explain this?
I never saw this message, may be change it to assertion, as proposed
in phk comment, is reasonable. I do not have an opinion.
I asked about it in my message from 3rd of May and also there I've
proposesed following patch for calcru1():
- if ((int64_t)tu 0) {
- /* XXX: this should be an assert /phk */
- printf(calcru: negative runtime of %jd usec for pid %d
(%s)\n,
- (intmax_t)tu, p-p_pid, p-p_comm);
- tu = ruxp-rux_tu;
- }
+ KASSERT((int64_t)tu 0, (calcru: negative runtime of %jd usec
+ for pid %d (%s)\n,
+ (intmax_t)tu, p-p_pid, p-p_comm));
--
Alexander Krizhanovsky
NatSys Lab. (http://natsys-lab.com)
tel: +7 (916) 717-3899, +7 (499) 747-6304
e-mail: a...@natsys-lab.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
bad RAM? prove it with a crash dump?
i suspect i've got bad RAM but memtest has run through several dozen iterations without a problem. my (3 year old) laptop will run for a few days or weeks and then crash/freeze/hang. i've enabled crash dumps and i'm wondering if/how the dump might be able to (dis)prove that the RAM is bad. any ideas? thanks... -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - What luck for rulers, that men do not think. -- Adolf Hitler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Converting pointer to vm_offset_t
Just cast the point to vm_offset_t. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bad RAM? prove it with a crash dump?
Atom Smasher wrote: i suspect i've got bad RAM but memtest has run through several dozen iterations without a problem. my (3 year old) laptop will run for a few days or weeks and then crash/freeze/hang. i've enabled crash dumps and i'm wondering if/how the dump might be able to (dis)prove that the RAM is bad. any ideas? thanks... My experience with bad memory is that if it causes the machine to crash, it won't always happen while the machine is running the same process (or kernel thread)--so look for it crashing in a wide variety of places--and upon inspection of the core dump, a pointer somewhere will be pointing to garbage. -Boris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bad RAM? prove it with a crash dump?
On Thursday 06 May 2010 4:57:05 am Atom Smasher wrote: i suspect i've got bad RAM but memtest has run through several dozen iterations without a problem. my (3 year old) laptop will run for a few days or weeks and then crash/freeze/hang. i've enabled crash dumps and i'm wondering if/how the dump might be able to (dis)prove that the RAM is bad. any ideas? If you can find a bad pointer that has a single-bit error that can certainly point to bad memory. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bad RAM? prove it with a crash dump?
On Thu, 6 May 2010, Boris Kochergin wrote: My experience with bad memory is that if it causes the machine to crash, it won't always happen while the machine is running the same process (or kernel thread)--so look for it crashing in a wide variety of places--and upon inspection of the core dump, a pointer somewhere will be pointing to garbage. so really i'd need to collect two or more crash dumps, and if they point to different addresses then i can reasonably say the RAM is bad? thanks... -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - You don't get everything you want. A dictatorship would be a lot easier. -- George dubya Bush, describing what it's like to be governor of Texas. (Governing Magazine 7/98) If this were a dictatorship, it would be a heck of a lot easier, just so long as I'm the dictator. -- George dubya Bush http://www.cnn.com/TRANSCRIPTS/0012/18/nd.01.html 18 Dec 2000 CNN.com A dictatorship would be a heck of a lot easier, there's no question about it. George dubya Bush, 27 Jul 2001 Associated Press ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: bad RAM? prove it with a crash dump?
owner-freebsd-hack...@freebsd.org wrote: On Thu, 6 May 2010, Boris Kochergin wrote: My experience with bad memory is that if it causes the machine to crash, it won't always happen while the machine is running the same process (or kernel thread)--so look for it crashing in a wide variety of places--and upon inspection of the core dump, a pointer somewhere will be pointing to garbage. so really i'd need to collect two or more crash dumps, and if they point to different addresses then i can reasonably say the RAM is bad? thanks... It's not just that they point to different addresses, it is garbage in many completely independent places. For example, pulling bad registers/return addresses off the stack, or garbage in random unrelated buffers/structures/pointers. On the other hand, if you often have garbage in some structure's foo pointer, that indicates a problem (maybe locking) in how your code manages setting that foo pointer. It's a subtle difference. It is also useful to make sure that the garbage itself is different. As mentioned before, a single bit error in an otherwise valid value, or maybe a missing/scrambled byte, these are good indications of memory problems. If random places are often overwritten with something else, that could just be another piece of misbehaving code that is writing someplace it shouldn't. I've often found code that writes some buffer into e.g. a piece of memory it no longer owns that looks like memory corruption until you realize the garbage is always something specific like a vnode structure. /Andrew ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
How to get data from kernel module ?
Hi, I am creating a kernel module and I need to get some information from that module. I can do this with ioctl and pass the data to the user space but it seems a bit unpractical to me, because I do not know the amount of the data - it can differ. I do not know of any way to pass a list of structures to the userspace through ioctl - is there any? So my question is, is there any standard way in FreeBSD to do this ? In linux I would probably use the sysfs, but in FreeBSD I can not find anything similar, except just creating some virtual filesystem on my own and obviously this is not what I want to do. Thanks! -Lukas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] RUSAGE_THREAD
On Thu, May 06, 2010 at 04:42:39PM +0400, Alexander Krizhanovsky wrote:
On 05/05/10 01:24, Kostik Belousov wrote:
On Wed, May 05, 2010 at 12:48:53AM +, Alexander Krizhanovsky wrote:
Konstantin,
Concerning i/o counters we collect them in rucollect() in for loop and
update in various places, for example in vfs_bio.c. Rusage of an exiting
threads is handled in exit1() - ruadd().
Your version of the patch certainly is more robust, however I'm still
concerning about following things, which could be done better:
1) Zeroing of thread runtime statistic looks fine if we use it only for
whole process statistic calculating, but now (when it's also used as is
for the thread statistic) it should be handled independently, i.e.
RUSAGE_{SELF,CHILDREN} calls should not affect the thread structures
somehow. So I suppose we need to introduce some new counters to proc
structure and counters update code (it was stopped me to go on this way).
What do you mean by zeroing of thread runtime statistic ? Can you, please,
point me to exact location in code ? I did not found such code when
I did initial review of your patch.
I did testing by repeatedly calling getrusage with alternated
RUSAGE_SELF/RUSAGE_THREAD commands, and got sane increasing snapshots
of statistic.
I meant zeroing of per-thread statistic in ruxagg() after updating of
the whole process time counters.
I still do not understand which code you are referencing. Please note that
ruxagg() does not clear any thread statistic. It does clear the accumulated
tick counts for the thread after moving them _both_ to per-process and
per-thread resource usage storage.
Please see the HEAD code that contains the committed patch.
2) With first in mind, getruasge(RUSAGE_THREAD) is called in current
thread and doesn't affect or use information from other threads, so it
definitely should use less number of locks, may be with atomic
operations for read-update-write operations. In fact the same getting
per-thread statistic in Linux is done _without_ locks at all (however
Linux uses different process/thread model).
thread_lock() is spinlock, and it disables preemption. calcru1() is
very sensible to have ticks counters to be in consistent state.
You can look at kern_time.c implementation of CLOCK_THREAD_CPUTIME_ID,
where indeed only preepmtion is disabled by use of critical section.
On the other hand, td_rux is accessed by other threads, and caclru1()
updates should be properly syncronized. Since thread_lock would
be needed for this, and it would give slightly more consistent results
for the copy of td_ru, I used it.
I do not think that thread_lock for running thread is a bottleneck,
and getrusage definitely should be not a contention point for properly
written application.
Yes, you're right - if we wish to have lockless thread accounting, then
we need to redesign the whole rusage accounting, so I'm voting for
commit of the patch.
Patch was committed two days ago.
Indeed, I concerned more about PROC_LOCK/PROC_SLOCK - they are acquired
both in kern_getrusage() and could be a problem in multithreaded process
with intensive performance accounting in threads. This happens for
example in resource accounting systems for shared hosting which are
solved by custom extensions of Apache, MySQL and other servers.
We still need per-process lock for resource summation code. On the other
hand, I do not understand why p_rux have to be protected by spinlock and
not by process mutex. Hm, spinlock disables preemption, but only for
curthread, Process spinlock is not acquired in the mi_switch(), so I
really do not see a reason not to change protection to mutex.
Any idea ?
If we're in time and it really looks like a problem (is getrusage() ever
a hotspot?) I can try to prepare the patch with less locking on this
weekend.
Also I still don't understand the sanity check in calccru1() for
negativeness of tu ( (int64_t)tu 0 ) - is it reachable? It seems that
it is possible only after about 300 thousand years of uptime... Could
you please explain this?
I never saw this message, may be change it to assertion, as proposed
in phk comment, is reasonable. I do not have an opinion.
I asked about it in my message from 3rd of May and also there I've
proposesed following patch for calcru1():
- if ((int64_t)tu 0) {
- /* XXX: this should be an assert /phk */
- printf(calcru: negative runtime of %jd usec for pid %d
(%s)\n,
- (intmax_t)tu, p-p_pid, p-p_comm);
- tu = ruxp-rux_tu;
- }
+ KASSERT((int64_t)tu 0, (calcru: negative runtime of %jd usec
+ for pid %d (%s)\n,
+ (intmax_t)tu, p-p_pid, p-p_comm));
I did understand your proposal, but, as I said, I have no opinion.
Re: How to get data from kernel module ?
On Thu, May 06, 2010 at 03:38:30PM +0200, LukᨠCzerner wrote: Hi, I am creating a kernel module and I need to get some information from that module. I can do this with ioctl and pass the data to the user space but it seems a bit unpractical to me, because I do not know the amount of the data - it can differ. I do not know of any way to pass a list of structures to the userspace through ioctl - is there any? So my question is, is there any standard way in FreeBSD to do this ? In linux I would probably use the sysfs, but in FreeBSD I can not find anything similar, except just creating some virtual filesystem on my own and obviously this is not what I want to do. sysctl(3) seems to be the usual way of getting information from the kernel. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
QTDIR?
When compiling some QT4 based programs from source, the configure script asks for $QTDIR. On Debian and other systems, there's a single QT root with symlinks to the real locations: $ ls -alF /usr/share/qt4/ total 356 drwxr-xr-x 6 root root 4096 2010-05-05 15:01 ./ drwxr-xr-x 187 root root 4096 2010-05-06 02:16 ../ drwxr-xr-x 2 root root 4096 2010-05-05 15:01 bin/ drwxr-xr-x 3 root root 4096 2010-05-05 15:01 doc/ lrwxrwxrwx 1 root root 17 2010-05-05 15:01 include - ../../include/qt4/ drwxr-xr-x 99 root root 4096 2010-05-05 15:01 mkspecs/ lrwxrwxrwx 1 root root 21 2010-05-05 15:01 plugins - ../../lib/qt4/plugins/ -rw-r--r-- 1 root root 31 2010-02-11 15:55 q3porting.xml drwxr-xr-x 2 root root 4096 2010-05-05 15:01 translations/ On FreeBSD, there doesn't seem to be any such directory (meaning some programs actually become impossible to compile as they want to look in one place for their includes/binaries and can't do so). Is there are directory I'm not aware of, or am I going to have to do some manual surgery? xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: bad RAM? prove it with a crash dump?
On Thu, 6 May 2010, Andrew Duane wrote: It is also useful to make sure that the garbage itself is different. As mentioned before, a single bit error in an otherwise valid value, or maybe a missing/scrambled byte, these are good indications of memory problems. If random places are often overwritten with something else, that could just be another piece of misbehaving code that is writing someplace it shouldn't. I've often found code that writes some buffer into e.g. a piece of memory it no longer owns that looks like memory corruption until you realize the garbage is always something specific like a vnode structure. There are trickier things too. I once had a machine with bad cache memory where once in a while you would get a cache line that had come from somewhere else in memory. This was particularly vexing when it happened to an I/O buffer, and I wound up with a large zip file that had 32 bytes of libc.so somewhere in the middle... :-( And of course, swapping out the RAM wouldn't have fixed it. -- Nate Eldredge n...@thatsmathematics.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to get data from kernel module ?
On 5/6/10 6:38 AM, Lukáš Czerner wrote: Hi, I am creating a kernel module and I need to get some information from that module. I can do this with ioctl and pass the data to the user space but it seems a bit unpractical to me, because I do not know the amount of the data - it can differ. I do not know of any way to pass a list of structures to the userspace through ioctl - is there any? So my question is, is there any standard way in FreeBSD to do this ? In linux I would probably use the sysfs, but in FreeBSD I can not find anything similar, except just creating some virtual filesystem on my own and obviously this is not what I want to do. you can add a sysctl to pass out arbitrary information very easily. It's up to you to decide where you want to put it in the sysctl tree. Thanks! -Lukas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bad RAM? prove it with a crash dump?
On Thu, 6 May 2010, Atom Smasher wrote: i suspect i've got bad RAM but memtest has run through several dozen iterations without a problem. my (3 year old) laptop will run for a few days or weeks and then crash/freeze/hang. i've enabled crash dumps and i'm wondering if/how the dump might be able to (dis)prove that the RAM is bad. any ideas? thanks... Do not discount other hardware problems: video cards, bad capacitors and power supplies. Sadly, I mention these as a subset of my experience. :( I have even had a faulty left mouse button that would lock my X server (many years ago). While holding the button down (scrolling through a menu), the mouse would release and acquire too quickly for the server. Unfortunately, it is harder to find the problem in a laptop where you cannot easily (if at all) switch out pieces of hardware to find the problem. Have you investigated whether or not the laptop is overheating? Sean -- s...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to get data from kernel module ?
On Thu, 6 May 2010, Julian Elischer wrote: Date: Thu, 06 May 2010 09:41:32 -0700 From: Julian Elischer jul...@elischer.org To: Lukáš Czerner czerner.lu...@gmail.com Cc: freebsd-hackers@freebsd.org Subject: Re: How to get data from kernel module ? On 5/6/10 6:38 AM, Lukáš Czerner wrote: Hi, I am creating a kernel module and I need to get some information from that module. I can do this with ioctl and pass the data to the user space but it seems a bit unpractical to me, because I do not know the amount of the data - it can differ. I do not know of any way to pass a list of structures to the userspace through ioctl - is there any? So my question is, is there any standard way in FreeBSD to do this ? In linux I would probably use the sysfs, but in FreeBSD I can not find anything similar, except just creating some virtual filesystem on my own and obviously this is not what I want to do. you can add a sysctl to pass out arbitrary information very easily. It's up to you to decide where you want to put it in the sysctl tree. Thank to you all for suggestions. I will look at the sysctl then. Thanks! -Lukas___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to get data from kernel module ?
On 05/06/10 15:38, Lukáš Czerner wrote: Hi, I am creating a kernel module and I need to get some information from that module. I can do this with ioctl and pass the data to the user space but it seems a bit unpractical to me, because I do not know the amount of the data - it can differ. I do not know of any way to pass a list of structures to the userspace through ioctl - is there any? So my question is, is there any standard way in FreeBSD to do this ? In linux I would probably use the sysfs, but in FreeBSD I can not find anything similar, except just creating some virtual filesystem on my own and obviously this is not what I want to do. As others said, sysctl is one way to go, but might not be very convenient if the amount of data is large. I'd rather setup a device and a simple protocol to read/write to/from it. http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-char.html (you want the 5+ version) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: bad RAM? prove it with a crash dump?
On 7/05/2010 2:50 AM, Sean C. Farley wrote: On Thu, 6 May 2010, Atom Smasher wrote: i suspect i've got bad RAM but memtest has run through several dozen iterations without a problem. my (3 year old) laptop will run for a few days or weeks and then crash/freeze/hang. i've enabled crash dumps and i'm wondering if/how the dump might be able to (dis)prove that the RAM is bad. any ideas? thanks... Do not discount other hardware problems: video cards, bad capacitors and power supplies. Sadly, I mention these as a subset of my experience. :( I have even had a faulty left mouse button that would lock my X server (many years ago). While holding the button down (scrolling through a menu), the mouse would release and acquire too quickly for the server. And to add the most obscure, the USB wireless kb/mouse adapter (or the keyboard/mouse itself) randomly crashing any operating system. Completely new PC with all components except that, reinstalled OS, change of OS, and it still crashed randomly. Swap the logitech adapter and the wireless keyboard/mouse that were locked to it, and all stability problems disappeared. Unfortunately, it is harder to find the problem in a laptop where you cannot easily (if at all) switch out pieces of hardware to find the problem. Have you investigated whether or not the laptop is overheating? Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] RUSAGE_THREAD
On Thu, 6 May 2010, Kostik Belousov wrote:
On Thu, May 06, 2010 at 04:42:39PM +0400, Alexander Krizhanovsky wrote:
...
Indeed, I concerned more about PROC_LOCK/PROC_SLOCK - they are acquired
both in kern_getrusage() and could be a problem in multithreaded process
with intensive performance accounting in threads. This happens for
example in resource accounting systems for shared hosting which are
solved by custom extensions of Apache, MySQL and other servers.
We still need per-process lock for resource summation code.
It's hard to see how it can be done without any lock at all. The
oldest example of per-CPU summation code is in vm_meter.c It doesn't
use any locks, but without any lock at all it is fundamentally broken.
Incoherencies in the data (due to reading and writing the counters at
different unsynchronized times in the past) would be more obvious for
times (except when the unsynchronized accesses give an off-by-2**32
error due to wraparound of a 32-bit counter), so I think getrusage()
should be more careful than vm_meter. calcru() already does a lot of
work and locking just to synchronize times relative to previous readings.
On the other
hand, I do not understand why p_rux have to be protected by spinlock and
not by process mutex. Hm, spinlock disables preemption, but only for
curthread,
It is probably mostly historical. The read-modify-write of pc_switchtime
and some other things used to be protected by splstatclock(). Hmm,
that was the lowest spl level, closer to a non-spin mutex than anything.
In RELENG_4, calcru() doesn't modify switchtime either, and mi_switch()
has comments saying that even the splstatclock() should be unnecessary.
RELENG_4 is of course non-preemptive, so it has close to the equivalent
of critical_enter() automatically.
Process spinlock is not acquired in the mi_switch(), so I
really do not see a reason not to change protection to mutex.
mi_switch)() holds thread lock, which is a special type of spinlock.
I think the following philosphy is adequate for reading times: the time
returned shall be no earlier than the time (according to a uniquely
selected clock at the point where the time is read) at the beginning of
the call, and coherent with itself. (It will be indeterminately far in
the past by the time that it gets back to the caller. Times read by a
single caller shall be monotonic, but times read by separate callers are
incomparable unless the callers do additional synchronization). Thus
the locked part of reading a clock is:
- lock sufficiently to synchronize the next step
- update memory copy of the time, so that it is not in the past
- drop locks needed for the update, but keep ones needed to prevent the
memory copy changing
- read and use the memory copy, reassembling it into the form needed by
the caller. This step may be long delayed from the update, but there
is no point in trying to minimize the delay for this step, since we
must soon drop all time-related locks and thus lose all control over
the delay seen by the caller.
Only in very critical kernel environments would it be necessary and
possible to hold strong locks to minimize the delay across the whole
operation of reading the time and acting on the result.
I asked about it in my message from 3rd of May and also there I've
proposesed following patch for calcru1():
- if ((int64_t)tu 0) {
- /* XXX: this should be an assert /phk */
- printf(calcru: negative runtime of %jd usec for pid %d
(%s)\n,
- (intmax_t)tu, p-p_pid, p-p_comm);
- tu = ruxp-rux_tu;
- }
+ KASSERT((int64_t)tu 0, (calcru: negative runtime of %jd usec
+ for pid %d (%s)\n,
+ (intmax_t)tu, p-p_pid, p-p_comm));
I did understand your proposal, but, as I said, I have no opinion.
This patch is mostly backwards:
- backwards condition in KASSERT()
- removal of KNF formatting
- removal of the fixup when the KASSERT() is null.
I think I prefer removing the whole statement. But the KASSERT() may be
useful for verifying that the failure case really is unreachable due to
programming bugs. I think it reachable due to hardware bugs, but only
ones that are less likely than a memory parity error, and the handling
of hardware bugs here shouldn't be to panic.
Bruce
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
