Re: ZFS committed to the FreeBSD base.



On Thu, Apr 12, 2007 at 01:51:59PM -0500, Craig Boston wrote:

For something this low level my opinion is it's better to stay with
compile time options. After all, in the above example, cmpxchg8 is a
single machine instruction. How much overhead does it add to retrieve a
variable from memory and check it, then jump to the correct place?
Enough that it outweighs the benefit of using that instruction in the
first place?

That's why I suggested the second method (to change fn pointers in the
device struct).

I agree this makes sense for some things, but atomic operations are
supposed to be as fast as possible -- preferably single machine
instructions I can't think of anything short of JIT compiling the kernel
that wouldn't be a high price to pay.

The problem is that ZFS would be compiled (by default) to work for many
platforms, and thus a majority of systems wouldn't get the nice
optimization. That's why I think we should do something along the lines of
doing a check for CX8 and changing the pointers in the vfsops and
vop_vector static structures, depending upon the availability of this
optimization.

I guess it really depends upon how much ZFS uses it; I got the sense that
it is "often".

-- Rick C. Petty
_______________________________________________
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: converting some autogenerated ruby code to C
    ... faster than the pure Ruby version. ... I'm wondering how much optimization has been done there. ... def test ... You would either have to generate and compile and load a C extension for _each_ call of *eval or somehow collect all the code to eval and do it all at once. ...
    (comp.lang.ruby)
  • Re: Cannot optimize 64bit Linux code
    ... It is a floating point intensive code and when I compile ... It seems like something is inhibiting the optimization. ... let's base everything on a variant of the "register" calling convention, and use SSE for all the floating point math rather than crufty old x87. ... my guess is that the calling convention was designed according to some misguided sense of "optimization wisdom", ...
    (comp.lang.c)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... > the existence of an instruction to draw the proper comparison. ... > memory address pointed to by register based on the tested condition. ... > case is precisely the differing object code for the unconditional branch, ... Won't compile as is ... ...
    (comp.lang.cobol)
  • Tricking pl1s production_table
    ... you're using debug and break statements to create a trace log. ... testprog: procedure options; ... I can't just go compile everything with -table ... which doesn't happen below optimization level 2. ...
    (comp.sys.stratus)
  • Re: Illegal instruction (core dumped)
    ... (snip regarding "Illegal instruction (core dumped)") ... > 1) overwriting the compiled code by writing to an invalid array ... any compile time errors. ...
    (comp.lang.fortran)