monitor+mwait and volatile-ish
Typical x86 MONITOR+MWAIT is like this (taken from Intel manual):
EAX = Logical Address(Trigger)
ECX = 0 (*Hints *)
EDX = 0 (* Hints *)
IF ( !trigger_store_happened) {
MONITOR EAX, ECX, EDX
IF ( !trigger_store_happened ) {
MWAIT EAX, ECX
}
}
In FreeBSD we have this helper function for MONITOR:
static __inline void
cpu_monitor(const void *addr, u_long extensions, u_int hints)
{
__asm __volatile(monitor
: : a (addr), c (extensions), d (hints));
}
Now, let's assume that 'Trigger' is a global variable and
'trigger_store_happened' is a check for a particular value in this variable.
Then, with current state of matters, we must either declare the global variable
to be volatile or use a volatile cast in the second IF. Otherwise, a compiler
is free to assume that the variable doesn't change between the first and the
second IF and drop the second IF altogether. And that would make MONITOR+MWAIT
to miss an event if it happens between the first check and MONITOR.
So what's my point.
- using volatile variable with cpu_monitor requires DEVOLATILE to silence
compiler warning about discarding volatile; this is unnecessary code bloat
- adding volatile cast in the checks is easy to forget and adds code bloat
Possible improvements:
- make the argument of cpu_monitor be 'const volatile void *', the most
permissive type; this would also be a hint that variable should be volatile
- add some magic dust to cpu_monitor that would tell compiler to not cache
the variable; right now I can only think of the memory constraint, but it
seems to be too big of a hummer
What do you think about this?
--
Andriy Gapon
___
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: monitor+mwait and volatile-ish
On Wed, Sep 26, 2012 at 11:14:41AM +0300, Andriy Gapon wrote:
Typical x86 MONITOR+MWAIT is like this (taken from Intel manual):
EAX = Logical Address(Trigger)
ECX = 0 (*Hints *)
EDX = 0 (* Hints *)
IF ( !trigger_store_happened) {
MONITOR EAX, ECX, EDX
IF ( !trigger_store_happened ) {
MWAIT EAX, ECX
}
}
In FreeBSD we have this helper function for MONITOR:
static __inline void
cpu_monitor(const void *addr, u_long extensions, u_int hints)
{
__asm __volatile(monitor
: : a (addr), c (extensions), d (hints));
}
Now, let's assume that 'Trigger' is a global variable and
'trigger_store_happened' is a check for a particular value in this variable.
Then, with current state of matters, we must either declare the global
variable
to be volatile or use a volatile cast in the second IF. Otherwise, a compiler
is free to assume that the variable doesn't change between the first and the
second IF and drop the second IF altogether. And that would make
MONITOR+MWAIT
to miss an event if it happens between the first check and MONITOR.
So what's my point.
- using volatile variable with cpu_monitor requires DEVOLATILE to silence
compiler warning about discarding volatile; this is unnecessary code bloat
- adding volatile cast in the checks is easy to forget and adds code bloat
Possible improvements:
- make the argument of cpu_monitor be 'const volatile void *', the most
permissive type; this would also be a hint that variable should be volatile
- add some magic dust to cpu_monitor that would tell compiler to not cache
the variable; right now I can only think of the memory constraint, but it
seems to be too big of a hummer
What do you think about this?
You might claim that the asm writes to *addr by specifying it in the
output constraint. This should fool the compiler into reload *addr after
the monitor execution.
pgpAahBMIChsi.pgp
Description: PGP signature
Re: monitor+mwait and volatile-ish
on 26/09/2012 12:10 Konstantin Belousov said the following:
On Wed, Sep 26, 2012 at 11:14:41AM +0300, Andriy Gapon wrote:
[snip]
So what's my point. - using volatile variable with cpu_monitor requires
DEVOLATILE to silence compiler warning about discarding volatile; this is
unnecessary code bloat - adding volatile cast in the checks is easy to
forget and adds code bloat
Possible improvements: - make the argument of cpu_monitor be 'const
volatile void *', the most permissive type; this would also be a hint
that variable should be volatile - add some magic dust to cpu_monitor
that would tell compiler to not cache the variable; right now I can only
think of the memory constraint, but it seems to be too big of a hummer
What do you think about this?
You might claim that the asm writes to *addr by specifying it in the output
constraint. This should fool the compiler into reload *addr after the
monitor execution.
You mean something like:
static __inline void
cpu_monitor(const void *addr, u_long extensions, u_int hints)
{
__asm __volatile(monitor
: =m (*(char *)addr)
: a (addr), c (extensions), d (hints));
}
This seems to do the job with base gcc, 4.6, 4.7 and clang.
Thank you!
--
Andriy Gapon
___
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
What's cooking for FreeBSD on wiki
Hello, Since I have less free time than necessary to properly maintain the What's cooking page(s), I've transitioned the one for FreeBSD 10, and hopefully future versions, to the FreeBSD wiki: http://wiki.freebsd.org/WhatsNew/FreeBSD10 This reduces the bus factor for this page and also allows everyone to add new information they think is necessary. I'll also participate in maintaining the wiki page, but please don't wait for me if you see something missing from it :) signature.asc Description: OpenPGP digital signature
Allocator sizeof operand mismatch
Clang Analyzer reports about 100 cases of Allocator sizeof operand mismatch, for example: http://scan.freebsd.your.org/freebsd-head/sbin.umount/2012-09-23-amd64/report-k4ThD9.html#EndPath The reports seem to be valid, but I'm no export. I can work out that the above should probably be fixed by changing sizeof(int) to sizeof(char) and that it incidentally works anyway since both types have the same size in most cases. But I probably won't detect if the error is somewhere else than the arguments to malloc/calloc. Is someone willing to help me fix these, or should I start filing PR's with patches? Thanks, Erik___ 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: gpart is junk
Date: Mon, 17 Sep 2012 08:54:41 -0400 From: deisc...@freebsd.org To: tevans...@googlemail.com CC: an...@hesiod.org; freebsd-hackers@freebsd.org Subject: Re: gpart is junk On Mon, 17 Sep 2012, Tom Evans wrote: On Sun, Sep 16, 2012 at 8:12 PM, Jeff Anton an...@hesiod.org wrote: … my point is that all this information needs to be together in one human and machine readable form. We need to be able to look at the whole picture of a device and say that makes sense then do it. And this shouldn't be from some GUI junk either. In a file, this information can be kept as a reference, as a confirmation that partitioning hasn't changed unexpectedly, and modified if needed in a clear manner. (Sorry to pick at just parts of your email…) The current GEOM configuration is available from a sysctl in machine readable format - check out kern.geom.confxml. If you are concerned about your partitions changing underneath you, storing and then comparing output from this sysctl gives you a simple way to determine what. A human readable version can be obtained from the gpart tool. IMHO, gpart and GEOM are fantastic. gpart is a much simpler tool to use than fdisk, and fully understands every kind of disk partitioning you can throw at it, whilst fdisk is only a tool for playing with MBR. The gpart man page explains clearly and concisely how to use it. GEOM provides a clear framework that anything can plug in to, from labels to whole disk encryption. It is not simple. All I want is Solaris format utility (partition and label). -- DE For someone such as myself- and others- who use PowerPC(64)/POWER systems, gpart is far from being junk. Fdisk is basically useless on an APM table or to even create such. You also have the choice of creating a partition scheme with a Linux live CD and then adjusting the partition types with gpart. You can use gparted. Maybe you haven't noticed that gpart givess you the option of different partition tables from the start. ___ 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
