1. 08 12月, 2006 4 次提交
  2. 22 11月, 2006 1 次提交
  3. 18 9月, 2006 1 次提交
    • S
      ieee1394: shrink tlabel pools, remove tpool semaphores · 9951903e
      Stefan Richter 提交于
      This patch reduces the size of struct hpsb_host and also removes
      semaphores from ieee1394_transactions.c.  On i386, struct hpsb_host
      shrinks from 10656 bytes to 6688 bytes.  This is accomplished by
       - using a single wait_queue for hpsb_get_tlabel instead of many
         instances of semaphores,
       - using a single lock to serialize access to all tlabel pools (the
         protected code regions are small, i.e. lock contention very low),
       - omitting the sysfs attribute tlabels_allocations.
      
      Drawback:  In the rare case that a process needs to sleep because all
      transaction labels for the node are temporarily exhausted, it is also
      woken up if a tlabel for a different node became free, checks for an
      available tlabel, and is put to sleep again.  The check is not costly
      and the situation occurs extremely rarely.  (Tlabels are typically
      only exhausted if there was no context switch to the khpsbpkt thread
      which recycles tlables.)  Therefore the benefit of reduced tpool size
      outweighs this drawback.
      
      The sysfs attributes tlabels_free and tlabels_mask are not compiled
      anymore unless CONFIG_IEEE1394_VERBOSEDEBUG is set.
      
      The by far biggest member of struct hpsb_host, the struct csr_control
      csr (5272 bytes on i386), is now placed at the end of struct hpsb_host.
      
      Note, hpsb_get_tlabel calls the macro wait_event_interruptible with a
      condition argument which has a side effect (allocation of a tlabel and
      manipulation of the packet).  This side effect happens only if the
      condition is true.  The patch relies on wait_event_interruptible not
      evaluating the condition again after it became true.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      9951903e
  4. 04 7月, 2006 2 次提交
    • I
      [PATCH] lockdep: annotate ieee1394 skb-queue-head locking · d3788348
      Ingo Molnar 提交于
      ieee1394 reuses the skb infrastructure of the networking code, and uses two
      skb-head queues: ->pending_packet_queue and hpsbpkt_queue.  The latter is used
      in the usual fashion: processed from a kernel thread.  The other one,
      ->pending_packet_queue is also processed from hardirq context (f.e.  in
      hpsb_bus_reset()), which is not what the networking code usually does (which
      completes from softirq or process context).  This locking assymetry can be
      totally correct if done carefully, but it can also be dangerous if networking
      helper functions are reused, which could assume traditional networking use.
      
      It would probably be more robust to push this completion into a workqueue -
      but technically the code can be 100% correct, and lockdep has to be taught
      about it.  The solution is to split the ->pending_packet_queue skb-head->lock
      class from the networking lock-class by using a private lock-validator key.
      
      Has no effect on non-lockdep kernels.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: Jody McIntyre <scjody@modernduck.com>
      Cc: Ben Collins <bcollins@debian.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d3788348
    • S
      [PATCH] ieee1394: fix kerneldoc of hpsb_alloc_host · 3c6c65f5
      Stefan Richter 提交于
      There was stuff between the comment and the function.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NBen Collins <bcollins@ubuntu.com>
      3c6c65f5
  5. 01 7月, 2006 1 次提交
  6. 27 6月, 2006 1 次提交
  7. 13 6月, 2006 1 次提交
  8. 02 12月, 2005 1 次提交
  9. 07 11月, 2005 1 次提交
  10. 01 10月, 2005 1 次提交
  11. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4