1. 26 Jun, 2015 1 commit
    • Kirill Smelkov's avatar
      tests: Allow to test with ZEO & NEO ZODB storages · 7fc4ec66
      Kirill Smelkov authored
      Previously we were always testing with DBs backed up by FileStorage. Now
      we provide a way to run the testsuite with user selected storage
      backend:
      
          $ WENDELIN_CORE_TEST_DB="<fs>"   make test.py     # test with temporary db with FileStorage
          $ WENDELIN_CORE_TEST_DB="<zeo>"  make test.py     # ----------//---------- with ZEO
          $ WENDELIN_CORE_TEST_DB="<neo>"  make test.py     # ----------//---------- with NEO
      
          $ WENDELIN_CORE_TEST_DB=neo://db@master  make test.py     # test with externally provided DB
      
      Default is still to run tests with FileStorage.
      
      /cc @jm
      7fc4ec66
  2. 25 Jun, 2015 2 commits
  3. 02 Jun, 2015 3 commits
  4. 29 Apr, 2015 1 commit
    • Kirill Smelkov's avatar
      bigfile/ram_shmfs: Try to support compiling on older systems · 48defba0
      Kirill Smelkov authored
      For example on Debian 7 Wheezy the kernel (linux 3.2) supports holepunching,
      because holepunching was added in linux 2.6.38:
      
          http://git.kernel.org/linus/79124f18b335172e1916075c633745e12dae1dac
      
      but glibc does not provide fallocate mode constants, and compilation fails:
      
          gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -D_GNU_SOURCE -I./include -I./3rdparty/ccan -I./3rdparty/include -I/opt/slapgrid/f2a5f59d0d2b521681b9333ee76a2859/parts/python2.7/include/python2.7 -c bigfile/ram_shmfs.c -o build/temp.linux-x86_64-2.7/bigfile/ram_shmfs.o -std=gnu99 -fplan9-extensions -fvisibility=hidden -Wno-declaration-after-statement -Wno-error=declaration-after-statement
          bigfile/ram_shmfs.c: In function ‘shmfs_drop_memory’:
          bigfile/ram_shmfs.c:135:31: error: ‘FALLOC_FL_PUNCH_HOLE’ undeclared (first use in this function)
          bigfile/ram_shmfs.c:135:31: note: each undeclared identifier is reported only once for each function it appears in
          bigfile/ram_shmfs.c:135:54: error: ‘FALLOC_FL_KEEP_SIZE’ undeclared (first use in this function)
          error: command 'gcc' failed with exit status 1
      
      Try to fix it via fallbacking to provide the needed defines on older systems ourselves.
      
      Cc: Klaus Wölfel <klaus@nexedi.com>
      Cc: Ivan Tyagov <ivan@tyagov.com>
      48defba0
  5. 03 Apr, 2015 11 commits
    • Kirill Smelkov's avatar
      bigfile: Basic benchmarks · bb9d8bf1
      Kirill Smelkov authored
          - for virtual memory subsytem
          - for ZBigFiles
      
      They are not currently great, e.g. for virtmem we have in-kernel
      overhead of page clearing - in perf profiles, for bigfile_mmap compared
      to file_read kernel's clear_page_c raises significantly.
      
      That is the worker for clearing page memory and we currently cannot
      avoid that - any memory obtained from kernel (MAP_ANONYMOUS, mmap(file)
      with hole, etc...) comes pre-initialized to zeros to userspace.
      
      This can be seen in the benchmarks as well: file_readbig differs from
      file_read in only that the latter uses 1 small buffer and the first
      allocates large memory (cleared by kernel + python does the memset).
      
          bigfile/tests/bench_virtmem.py@125::bench_file_mmap_adler32     0.47  (0.86 0.49 0.47)
          bigfile/tests/bench_virtmem.py@126::bench_file_read_adler32     0.69  (1.11 0.71 0.69)
          bigfile/tests/bench_virtmem.py@127::bench_file_readbig_adler32  1.41  (1.70 1.42 1.41)
          bigfile/tests/bench_virtmem.py@128::bench_bigfile_mmap_adler32  1.42  (1.45 1.42 1.51)
      
          bigfile/tests/bench_virtmem.py@130::bench_file_mmap_md5         1.52  (1.91 1.54 1.52)
          bigfile/tests/bench_virtmem.py@131::bench_file_read_md5         1.73  (2.10 1.75 1.73)
          bigfile/tests/bench_virtmem.py@132::bench_file_readbig_md5      2.44  (2.73 2.46 2.44)
          bigfile/tests/bench_virtmem.py@133::bench_bigfile_mmap_md5      2.40  (2.48 2.40 2.53)
      
      There is MAP_UNINITIALIZED which works only for non-mmu targets and only
      if explicitly allowed when configuring kernel (off by default).
      
      There were patches to disable that pages zeroing, as it gives
      significant speedup for people's workloads, e.g. [1,2] but all of them
      did not got merged for security reasons.
      
      [1] http://marc.info/?t=132691315900001&r=1&w=2
      [2] http://thread.gmane.org/gmane.linux.kernel/548926
      
      ~~~~
      
      For ZBigFile - it is the storage who is dominating in profiles.
      bb9d8bf1
    • Kirill Smelkov's avatar
      bigfile: BigFile backend to store data in ZODB · 4174b84a
      Kirill Smelkov authored
      This adds transactionality and with e.g. NEO[1] allows to distribute
      objects to nodes into cluster.
      
      We hook into ZODB two-phase commit process as a separate data manager,
      and synchronize changes to memory, to changes to object only at that
      time.
      
      Alternative would be to get notified on every page change, and mark
      appropriate object as dirty right at that moment.
      
      But I wanted to stay close to filesystem design (we don't get
      notification for every file change from kernel) - that's why it is done
      the first way.
      
      [1] http://www.neoppod.org/
      4174b84a
    • Kirill Smelkov's avatar
      bigfile: BackFile backend to store data in an OS file · b3910de8
      Kirill Smelkov authored
      In Python. To demonstrate how backends could be implemented and test
      system on simple things.
      b3910de8
    • Kirill Smelkov's avatar
      bigfile: Python wrapper around virtual memory subsystem · 35eb95c2
      Kirill Smelkov authored
      Exposes BigFile - this way users can define BigFile backend in Python.
      
      Also exposed are BigFile handles, and VMA objects which are results of
      mmaping.
      35eb95c2
    • Kirill Smelkov's avatar
      bigfile/virtmem: Userspace Virtual Memory Manager · 9a293c2d
      Kirill Smelkov authored
      Does similar things to what kernel does - users can mmap file parts into
      address space and access them read/write. The manager will be getting
      invoked by hardware/OS kernel for cases when there is no page loaded for
      read, or when a previousle read-only page is being written to.
      
      Additionally to features provided in kernel, it support to be used to
      store back changes in transactional way (see fileh_dirty_writeout()) and
      potentially use huge pages for mappings (though this is currently TODO)
      9a293c2d
    • Kirill Smelkov's avatar
      bigfile: RAM subsystem · 8c935a5f
      Kirill Smelkov authored
      This thing allows to get aliasable RAM from OS kernel and to manage it.
      Currently we get memory from a tmpfs mount, and hugetlbfs should also
      work, but is TODO because hugetlbfs in the kernel needs to be improved.
      
      We need aliasing because we'll need to be able to memory map the same
      page into several places in address space, e.g. for taking two slices
      overlapping slice of the same array at different times.
      
      Comes with test programs that show we aliasing does not work for
      anonymous memory.
      8c935a5f
    • Kirill Smelkov's avatar
      bigfile: Stub for virtmem · 77d61533
      Kirill Smelkov authored
      This will be the core of virtual memory subsystem. For now we just
      define a structure to describe pages of memory and add utility to
      allocate address space from OS.
      77d61533
    • Kirill Smelkov's avatar
      Low-level pagefault handler · 6f7d4d64
      Kirill Smelkov authored
      We hook into SIGSEGV and handle read/write pagefaults this way.
      
      In this patch there goes stub code that only detects faults and
      determines (in arch specific way) whether fault was for read or write
      and there is a TODO to pass that information to higher level.
      
      It also comes with tests to detect we still crash if we access something
      incorrectly, so people could have coredumps and investigate them.
      6f7d4d64
    • Kirill Smelkov's avatar
      bigfile/pagemap: specialized {} uint64 -> void * mapping · 45af76e6
      Kirill Smelkov authored
      For BigFiles we'll needs to maintain `{} offset-in-file -> void *` mapping. A
      hash or a binary tree could be used there, but since we know files are
      most of the time accessed sequentially and locally in pages-batches, we
      can also organize the mapping in batches of keys.
      
      Specifically offset bits are so divided into parts, that every part
      addresses 1 entry in a table of hardware-page in size. To get to the actual
      value, the system lookups first table by first part of offset, then from
      first table and next part from address - second table, etc.
      
      To clients this looks like a dictionary with get/set/del & clear methods,
      but lookups are O(1) time always, and in contrast to hashes values are
      stored with locality (= adjacent lookups almost always access the same tables).
      45af76e6
    • Kirill Smelkov's avatar
      Basic setup.py / Makefile to build/install/sdist stuff + bigfile.so skeleton · 5755a6b3
      Kirill Smelkov authored
      It is an early project decision to use gnu99 & Plan9 C extensions, to
      simplify C code.
      
      So far we only build stub wendelin/bigfile/_bigfile.so .
      
      Makefile is introduced because there will be targets which are easier to
      handle at make level. For end users no make knowledge is required -
      usual `python setup.py build|install|...` work, redirecting to make
      where necessary.
      
      As was promised (e870781d "Top-level in-tree import redirector")
      setup.py contains install-time hooks to handle in-tree wendelin.py and
      install it as a module namespace.
      
      For sdist, we just use `git ls-files` info if we are in a checkout.
      5755a6b3
    • Kirill Smelkov's avatar
      Start wendelin.bigfile module · 1e92c921
      Kirill Smelkov authored
      This will be a module to allow users to program custom file-like
      backends and latter memory-map content of files from the backend.
      
      For now just start the module structure.
      1e92c921