1. 30 12月, 2006 12 次提交
    • S
      Loop over pack_windows when inflating/accessing data. · 079afb18
      Shawn O. Pearce 提交于
      When multiple mmaps start getting used for all pack file access it
      is not possible to get all data associated with a specific object
      in one contiguous memory region.  This limitation prevents simply
      passing a single address and length to SHA1_Update or to inflate.
      
      Instead we need to loop until we have processed all data of interest.
      
      As we loop over the data we are always interested in reusing the same
      window 'cursor', as the prior window will no longer be of any use
      to us.  This allows the use_pack() call to automatically decrement
      the use count of the prior window before setting up access for us
      to the next window.
      
      Within each loop we need to make use of the available length output
      parameter of use_pack() to tell us how many bytes are available in
      the current memory region, as we cannot tell otherwise.
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      079afb18
    • S
      Replace use_packed_git with window cursors. · 03e79c88
      Shawn O. Pearce 提交于
      Part of the implementation concept of the sliding mmap window for
      pack access is to permit multiple windows per pack to be mapped
      independently.  Since the inuse_cnt is associated with the mmap and
      not with the file, this value is in struct pack_window and needs to
      be incremented/decremented for each pack_window accessed by any code.
      
      To faciliate that implementation we need to replace all uses of
      use_packed_git() and unuse_packed_git() with a different API that
      follows struct pack_window objects rather than struct packed_git.
      
      The way this works is when we need to start accessing a pack for
      the first time we should setup a new window 'cursor' by declaring
      a local and setting it to NULL:
      
        struct pack_windows *w_curs = NULL;
      
      To obtain the memory region which contains a specific section of
      the pack file we invoke use_pack(), supplying the address of our
      current window cursor:
      
        unsigned int len;
        unsigned char *addr = use_pack(p, &w_curs, offset, &len);
      
      the returned address `addr` will be the first byte at `offset`
      within the pack file.  The optional variable len will also be
      updated with the number of bytes remaining following the address.
      
      Multiple calls to use_pack() with the same window cursor will
      update the window cursor, moving it from one window to another
      when necessary.  In this way each window cursor variable maintains
      only one struct pack_window inuse at a time.
      
      Finally before exiting the scope which originally declared the window
      cursor we must invoke unuse_pack() to unuse the current window (which
      may be different from the one that was first obtained from use_pack):
      
        unuse_pack(&w_curs);
      
      This implementation is still not complete with regards to multiple
      windows, as only one window per pack file is supported right now.
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      03e79c88
    • S
      Refactor how we open pack files to prepare for multiple windows. · 9bc879c1
      Shawn O. Pearce 提交于
      To efficiently support mmaping of multiple regions of the same pack
      file we want to keep the pack's file descriptor open while we are
      actively working with that pack.  So we are now keeping that file
      descriptor in packed_git.pack_fd and closing it only after we unmap
      the last window.
      
      This is going to increase the number of file descriptors that are
      in use at once, however that will be bounded by the total number of
      pack files present and therefore should not be very high.  It is
      a small tradeoff which we may need to revisit after some testing
      can be done on various repositories and systems.
      
      For code clarity we also want to seperate out the implementation
      of how we open a pack file from the implementation which locates
      a suitable window (or makes a new one) from the given pack file.
      Since this is a rather large delta I'm taking advantage of doing
      it now, in a fairly isolated change.
      
      When we open a pack file we need to examine the header and trailer
      without having a mmap in place, as we may only need to mmap
      the middle section of this particular pack.  Consequently the
      verification code has been refactored to make use of the new
      read_or_die function.
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      9bc879c1
    • S
      Create read_or_die utility routine. · 75025ccd
      Shawn O. Pearce 提交于
      Like write_or_die read_or_die reads the entire length requested
      or it kills the current process with a die call.
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      75025ccd
    • S
      Use off_t for index and pack file lengths. · 2dc3a234
      Shawn O. Pearce 提交于
      Since the index_size and pack_size members of struct packed_git
      are the lengths of those corresponding files we should use the
      off_t size of the operating system to store these file lengths,
      rather than an unsigned long.  This would help in the future should
      we ever resurrect Junio's 64 bit index implementation.
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      2dc3a234
    • S
      Refactor packed_git to prepare for sliding mmap windows. · c41ee586
      Shawn O. Pearce 提交于
      The idea behind the sliding mmap window pack reader implementation
      is to have multiple mmap regions active against the same pack file,
      thereby allowing the process to mmap in only the active/hot sections
      of the pack and reduce overall virtual address space usage.
      
      To implement this we need to refactor the mmap related data
      (pack_base, pack_use_cnt) out of struct packed_git and move them
      into a new struct pack_window.
      
      We are refactoring the code to support a single struct pack_window
      per packfile, thereby emulating the prior behavior of mmap'ing the
      entire pack file.
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      c41ee586
    • S
      Introduce new config option for mmap limit. · 77ccc5bb
      Shawn O. Pearce 提交于
      Rather than hardcoding the maximum number of bytes which can be
      mmapped from pack files we should make this value configurable,
      allowing the end user to increase or decrease this limit on a
      per-repository basis depending on the size of the repository
      and the capabilities of their operating system.
      
      In general users should not need to manually tune such a low-level
      setting within the core code, but being able to artifically limit
      the number of bytes which we can mmap at once from pack files will
      make it easier to craft test cases for the new mmap sliding window
      implementation.
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      77ccc5bb
    • S
      Replace unpack_entry_gently with unpack_entry. · 4d703a1a
      Shawn O. Pearce 提交于
      The unpack_entry_gently function currently has only two callers:
      the delta base resolution in sha1_file.c and the main loop of
      pack-check.c.  Both of these must change to using unpack_entry
      directly when we implement sliding window mmap logic, so I'm doing
      it earlier to help break down the change set.
      
      This may cause a slight performance decrease for delta base
      resolution as well as for pack-check.c's verify_packfile(), as
      the pack use counter will be incremented and decremented for every
      object that is unpacked.
      Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      4d703a1a
    • J
      Merge branch 'jc/curl' · 1ed4813f
      Junio C Hamano 提交于
      * jc/curl:
        Work around http-fetch built with cURL 7.16.0
      1ed4813f
    • J
      Fix 'git add' with .gitignore · 4d06f8ac
      Junio C Hamano 提交于
      When '*.ig' is ignored, and you have two files f.ig and d.ig/foo
      in the working tree,
      
      	$ git add .
      
      correctly ignored f.ig but failed to ignore d.ig/foo.  This was
      caused by a thinko in an earlier commit 4888c534, when we tried
      to allow adding otherwise ignored files.
      
      After reverting that commit, this takes a much simpler approach.
      When we have an unmatched pathspec that talks about an existing
      pathname, we know it is an ignored path the user tried to add,
      so we include it in the set of paths directory walker returned.
      
      This does not let you say "git add -f D" on an ignored directory
      D and add everything under D.  People can submit a patch to
      further allow it if they want to, but I think it is a saner
      behaviour to require explicit paths to be spelled out in such a
      case.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      4d06f8ac
    • J
      Revert "read_directory: show_both option." · c889763b
      Junio C Hamano 提交于
      This reverts commit 4888c534.
      c889763b
    • J
      8757749e
  2. 29 12月, 2006 9 次提交
  3. 28 12月, 2006 19 次提交