commit-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[SCM] Hurd branch, master, updated. v0.5-466-g9480792


From: Justus Winter
Subject: [SCM] Hurd branch, master, updated. v0.5-466-g9480792
Date: Mon, 03 Nov 2014 12:46:42 +0000

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Hurd".

The branch, master has been updated
       via  9480792609c779516ac465ac5a038101032be77d (commit)
      from  282e4ae275dc1b9b0b5bba6eb1b145cd1e80fa33 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 9480792609c779516ac465ac5a038101032be77d
Author: Justus Winter <address@hidden>
Date:   Thu Apr 17 15:44:12 2014 +0200

    libpager: use a fixed number of threads
    
    Previously, libpager used an unbounded number of threads to receive
    messages from the pager bucket.  It used sequence barriers to execute
    the requests to order requests to each object.
    
    The sequence barriers are implemented in seqnos.c.  A server function
    uses _pager_wait_for_seqno to wait for its sequence number and
    _pager_release_seqno to release it, or it uses _pager_update_seqno to
    do both operations in one step.
    
    These sequence barriers divide each server function in three parts: A,
    B, and C.  A_i happens "before" the sequence barrier i, B_i happens
    "in order", C_i happens "after" the sequence barrier.  This partial
    order < has the following properties:
    
    * This order is *per object*.  Requests to different objects are not
      ordered.
    
    * A_i < B_i,  B_i < C_i (due to the structure of the code)
    
    * B_i < B_{i+1} (this is due to the sequence barriers)
    
    * Note that only the B parts are ordered by the sequence numbers, we
      are free to execute C_i and C_{i+1} in any possible order.  The same
      argument applies to the A parts.
    
    The sequence barriers are implemented using a very simple ticket
    algorithm.  Every request, even the invalid ones, is processed by a
    thread, and waits until the ticket count reaches its seqno, does some
    work in-order, then increments the ticket and awakes all threads that
    have piled up up to this moment.  All of them except one will then
    discover that it's not their turn yet and go to sleep again.
    
    Creating one thread per request has proven to be problematic as
    memory_object requests often arrive in large batches.
    
    This patch does two things:
    
    * Use a single thread to receive messages from the port bucket.  All
      incoming request are put into a queue.
    
    * Use a fixed-number of threads (though even one is actually enough)
      to execute the the server functions.  If multiple threads are used,
      a work-delegation mechanism ensures that the per object order < is
      preserved.
    
    For reference, I used the following command to create workloads that
    highlight the problem this patch is addressing:
    
    % settrans t .../ext2fs --sync=30 /dev/sd2s1
    ...
    % /usr/bin/time zsh -c 'for ((i=0; i < 1500; i++)); do
      dd if=/dev/zero of=t/src/$i bs=4k count=290 2>/dev/null
      echo -n .
      if ((i % 100 == 0)) ; then echo -n $i; fi
    done'
    
    * libpager/queue.h: New file.
    * libpager/demuxer.c: Manage a queue of requests received from the
    port bucket.
    (pager_demuxer): Just decode the server function and enqueue the
    request.
    (worker_func): New function that consumes and executes the requests
    from the queue.
    (service_paging_requests): New function.
    (pager_start_workers): Likewise.
    * libpager/data-request.c: Remove the seqno barriers.
    * libpager/data-return.c: Likewise.
    * libpager/data-unlock.c: Likewise.
    * libpager/chg-compl.c: Likewise.
    * libpager/lock-completed.c: Likewise.
    * libpager/no-senders.c: Likewise.
    * libpager/notify-stubs.c: Likewise.
    * libpager/object-init.c: Likewise.
    * libpager/object-terminate.c: Likewise.
    * libpager/seqnos.c: Remove file.
    * libpager/stubs.c: Likewise.
    * libpager/pager.h (pager_demuxer): Drop declaration.
    (pager_start_workers): New declaration.
    * libpager/priv.h: Remove the _pager_seqno declarations.
    * libpager/Makefile (SRCS): Drop seqnos.c.
    * console/pager.c (user_pager_init): Call pager_start_workers.
    * libdiskfs/disk-pager.c: Likewise.
    * storeio/pager.c: Likewise.
    * ext2fs/pager.c (service_paging_requests): Remove function.
    (create_disk_pager): Start separate file pager using
    `pager_start_workers'.
    * fatfs/pager.c (service_paging_requests): Remove function.
    (create_fat_pager): Start separate file pager using
    `pager_start_workers'.

-----------------------------------------------------------------------

Summary of changes:
 console/pager.c             |   29 +----
 ext2fs/pager.c              |   28 +----
 fatfs/pager.c               |   28 +----
 libdiskfs/disk-pager.c      |   28 +----
 libpager/Makefile           |    2 +-
 libpager/chg-compl.c        |    4 +-
 libpager/data-request.c     |    3 -
 libpager/data-return.c      |    4 -
 libpager/data-unlock.c      |    5 -
 libpager/demuxer.c          |  287 +++++++++++++++++++++++++++++++++++++++++--
 libpager/lock-completed.c   |    2 -
 libpager/no-senders.c       |    1 -
 libpager/notify-stubs.c     |   10 --
 libpager/object-init.c      |    2 -
 libpager/object-terminate.c |    4 +-
 libpager/pager.h            |    7 +-
 libpager/priv.h             |    4 -
 libpager/queue.h            |   61 +++++++++
 libpager/seqnos.c           |   79 ------------
 libpager/stubs.c            |    9 --
 storeio/pager.c             |   26 +---
 21 files changed, 361 insertions(+), 262 deletions(-)
 create mode 100644 libpager/queue.h
 delete mode 100644 libpager/seqnos.c


hooks/post-receive
-- 
Hurd



reply via email to

[Prev in Thread] Current Thread [Next in Thread]