Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 07 2月, 2006 16 次提交
  3. 06 2月, 2006 7 次提交
    • T
      [PATCH] Fix "value computed is not used" compile warnings with gcc-4.1 · 911b0ad2
      由 Takashi Iwai 提交于 
      Fix gcc4.1 compile warnings "value computed is not used" with
set_current_state() and set_task_state() on i386/SMP and x86-64.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      911b0ad2
    • A
      [PATCH] jbd: fix transaction batching · fe1dcbc4
      由 Andrew Morton 提交于 
      Ben points out that:

  When writing files out using O_SYNC, jbd's 1 jiffy delay results in a
  significant drop in throughput as the disk sits idle.  The patch below
  results in a 4-5x performance improvement (from 6.5MB/s to ~24-30MB/s on my
  IDE test box) when writing out files using O_SYNC.

So optimise the batching code by omitting it entirely if the process which is
doing a sync write is the same as the one which did the most recent sync
write.  If that's true, we're unlikely to get any other processes joining the
transaction.

(Has been in -mm for ages - it took me a long time to get on to performance
testing it)

Numbers, on write-cache-disabled IDE:

/usr/bin/time -p synctest -n 10 -uf -t 1 -p 1 dir-name

Unpatched:
	40 seconds
Patched:
	35 seconds
Batching disabled:
	35 seconds

This is the problematic single-process-doing-fsync case.  With multiple
fsyncing processes the numbers are AFACIT unaltered by the patch.

Aside: performance testing and instrumentation shows that the transaction
batching almost doesn't help (testing with synctest -n 1 -uf -t 100 -p 10
dir-name on non-writeback-caching IDE).  This is because by the time one
process is running a synchronous commit, a bunch of other processes already
have a transaction handle open, so they're all going to batch into the same
transaction anyway.

The batching seems to offer maybe 5-10% speedup with this workload, but I'm
pretty sure it was more important than that when it was first developed 4-odd
years ago...

Cc: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fe1dcbc4
    • A
      [PATCH] reiserfs_get_acl() build fix · bc5e483d
      由 Andrew Morton 提交于 
      With CONFIG_REISERFS_FS_XATTR=y, CONFIG_REISERFS_FS_POSIX_ACL=n:

fs/reiserfs/xattr.c: In function `reiserfs_check_acl':
fs/reiserfs/xattr.c:1330: called object is not a function

Cc: Chris Mason <mason@suse.com>
Cc: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bc5e483d
    • P
      [PATCH] pktcdvd: Allow larger packets · 5c55ac9b
      由 Phillip Susi 提交于 
      The pktcdvd driver uses a compile time macro constant to define the maximum
supported packet length.  I changed this from 32 sectors to 128 sectors
because that allows over 100 MB of additional usable space on a 700 MB cdrw,
and increases throughput.

Note that you need a modified cdrwtool program that can format a CDRW disc
with larger packets to benefit from this change.
Signed-off-by: NPeter Osterlund <petero2@telia.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5c55ac9b
    • P
      [PATCH] pktcdvd: Don't waste kernel memory · e1bc89bc
      由 Peter Osterlund 提交于 
      Allocate memory for read-gathering at open time, when it is known just how
much memory is needed.  This avoids wasting kernel memory when the real packet
size is smaller than the maximum packet size supported by the driver.  This is
always the case when using DVD discs.
Signed-off-by: NPeter Osterlund <petero2@telia.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e1bc89bc
    • P
      [PATCH] pktcdvd: Fix overflow for discs with large packets · a460ad62
      由 Phillip Susi 提交于 
      The pktcdvd driver was using an 8 bit field to store the packet length
obtained from the disc track info.  This causes it to overflow packet length
values of 128KB or more.  I changed the field to 32 bits to fix this.

The pktcdvd driver defaulted to its maximum allowed packet length when it
detected a 0 in the track info field.  I changed this to fail the operation
and refuse to access the media.  This seems more sane than attempting to
access it with a value that almost certainly will not work.
Signed-off-by: NPeter Osterlund <petero2@telia.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a460ad62
    • L
      Revert "[PATCH] x86_64: Fix the node cpumask of a cpu going down" · cef50769
      由 Linus Torvalds 提交于 
      This reverts commit 10f4dc8b.

Quoth Andi Kleen:
  "Kiran decided that it makes the problem worse than it was before.
   Fixing it fully requires more work which is too much for 2.6.16.  So
   please revert that commit for now."
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cef50769
  5. 05 2月, 2006 10 次提交
  7. 04 2月, 2006 7 次提交