Re: Unfortunate dynamic linking for everything

From: Garance A Drosihn (drosih_at_rpi.edu)
Date: 11/19/03

  • Next message: Chris Shenton: "Re: Recovery? recent "make world" rendered system unusable (64 bit change)"
    Date: Wed, 19 Nov 2003 00:30:21 -0500
    To: Robert Watson <rwatson@freebsd.org>, David Schultz <das@freebsd.org>
    
    

    At 11:45 PM -0500 11/18/03, Robert Watson wrote:
    >
    >My feeling is we should all go away for a day or two, and run
    >our favorite macro-benchmark on our favorite sensitive dynamic
    >linking-sensitive application.

    I wish I had the time and background to implement one solution
    that I'd like to benchmark.

    have a: chflags ldcache /bin/sh

    When the loader goes to execute some binary, it checks for this
    ldcache flag. If set, it checks to see if it already has a
    cached copy of this program (probably checking based on a key
    of inode+lastchg for a match).

    If not, it links and loads the file into memory. It saves away
    a read-only copy of the result of that load. Then it does the
    appropriate magic to create a copy-on-write image of the loaded
    file, and executes that.

    If it already has a cached copy of that file, well, it just
    makes another copy-on-write image of the loaded file, and
    executes that. No I/O, no loading, no linking. Just RAM.

    Yes, disks have been getting bigger, but so has available memory.
    I think we would see a MUCH bigger win by taking advantage of
    that memory, than we will ever see by statically-linking system
    binaries. On the other hand, I have no idea if the above idea
    would be easy to implement in FreeBSD. It also needs to be a
    bit smarter than what I described, to cover the dynamic-library
    case (eg: the very PAM/NSS issue that we're interested in).

    If that isn't workable, I'm sure there are other strategies
    which could be imagined. Strategies which will give us more
    of a performance boost than static-linking these few programs
    will give us.

    -- 
    Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
    Senior Systems Programmer           or  gad@freebsd.org
    Rensselaer Polytechnic Institute    or  drosih@rpi.edu
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
    

  • Next message: Chris Shenton: "Re: Recovery? recent "make world" rendered system unusable (64 bit change)"

    Relevant Pages

    • Re: rundll32.exe consuming 98% of memory
      ... Rundll32.exe is a process which executes DLL's and places their libraries into memory. ... Will you please use Windows Explorer to search your hard disk for all copies of rundll32.exe and post a list of all the file paths to each. ... I have extracted and installed a clean copy of the file and the ...
      (microsoft.public.windowsxp.perform_maintain)
    • Re: DEFCON 16 and Hacking OpenVMS
      ... Therefore the code injected after the overflow executes some other ... Since there is no such thing as "shellcode" in VMS, ... area of memory to be executable and then branch to it. ... There sure is shellcode for OpenVMS, ...
      (comp.os.vms)
    • [REPOST] [PATCH] ARM: MMU: add a Non-cacheable Normal executable memory type
      ... memory; but for our purposes, it should be much faster than a full cache ... This patch has been entered into rmk's parch system as patch 5356/1. ... implementation of the DVFS code executes from OMAP on-chip SRAM, ... If the OCM RAM pages are marked as Cacheable, ...
      (Linux-Kernel)
    • Re: WinXP x64 - WriteFile() returns "Insufficient system resources exist to complete the request
      ... Since the MDL size field is still 16 bit, while its items are twice as ... bigger, I would not be surprised if the max memory for one MDL is now a bit ... >>VirtualAllocto make sure the memory alignment is correct. ... Buffers bigger than the combined hardware + drivers maximum ...
      (microsoft.public.win32.programmer.kernel)
    • Re: How to locate compiled binary code relative to source code?
      ... > distribution, but after compilation, I will encrypt these blocks in ... I decrypt the in-memory image of the encrypted part of code ... so lets assume I can pull that part off) It executes. ... > reencrypt the block in memory to ensure it is decrypted in memory only ...
      (microsoft.public.win32.programmer.kernel)

    Loading