- 30 Oct, 2009 3 commits
-
-
Akinobu Mita authored
Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Lothar Wassmann <LW@KARO-electronics.de> Signed-off-by:Andrew Morton <akpm@linux-foundation.org>
-
Akinobu Mita authored
1. s/iommu_area_free/bitmap_clear/ 2. s/iommu_area_reserve/bitmap_set/ 3. Use bitmap_find_next_zero_area instead of find_next_zero_area This cannot be simple substitution because find_next_zero_area doesn't check the last bit of the limit in bitmap 4. Remove iommu_area_free, iommu_area_reserve, and find_next_zero_area Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Akinobu Mita authored
bitmap_set: Set specified bit area bitmap_clear: Clear specified bit area bitmap_find_next_zero_area: Find free bit area These are mostly stolen from iommu helper. The differences are: - Use find_next_bit instead of doing test_bit for each bit - Rewrite bitmap_set and bitmap_clear Instead of setting or clearing for each bit. - Check the last bit of the limit iommu-helper doesn't want to find such area - The return value if there is no zero area find_next_zero_area in iommu helper: returns -1 bitmap_find_next_zero_area: return >= bitmap size Signed-off-by:
-
- 12 Nov, 2009 2 commits
-
-
Albin Tonnerre authored
Tested-by:
Wu Zhangjin <wuzhangjin@gmail.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Albin Tonnerre authored
use of this new compression method Signed-off-by:
Albin Tonnerre <albin.tonnerre@free-electrons.com> Acked-by:
H. Peter Anvin <hpa@zytor.com> Tested-by:
-
- 13 Nov, 2009 1 commit
-
-
Albin Tonnerre authored
and Russell King Signed-off-by:
-
- 12 Nov, 2009 4 commits
-
-
Albin Tonnerre authored
compression types - new piggy.lzo.S necessary for lzo compression - changes in arch/arm/boot/compressed/misc.c to allow the use of lzo or gzip, depending on the config - Kconfig support Signed-off-by:
-
Andrew Morton authored
Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Wu Zhangjin <wuzhangjin@gmail.com> Signed-off-by: -
Andrew Morton authored
#184: FILE: lib/decompress_unlzo.c:48: +static const unsigned char lzop_magic[] = + { 0x89, 0x4c, 0x5a, 0x4f, 0x00, 0x0d, 0x0a, 0x1a, 0x0a }; WARNING: line over 80 characters #254: FILE: lib/decompress_unlzo.c:118: + error("Both input pointer and fill function provided, don't know what to do"); WARNING: line over 80 characters #259: FILE: lib/decompress_unlzo.c:123: + error("NULL input pointer and missing position pointer or fill function"); WARNING: line over 80 characters #313: FILE: lib/decompress_unlzo.c:177: + r = lzo1x_decompress_safe((u8 *) in_buf, src_len, out_buf, &tmp); total: 1 errors, 3 warnings, 291 lines checked ./patches/lib-add-support-for-lzo-compressed-kernels.patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Wu Zhangjin <wuzhangjin@gmail.com> Signed-off-by: -
Albin Tonnerre authored
LZO-compressed kernel images, as well as support for using such images on the x86 and ARM architectures, and support for creating and using LZO-compressed initrd and initramfs images. This patch: The lzo compressor is worse than gzip at compression, but faster at extraction. Here are some figures for an ARM board I'm working on: Uncompressed size: 3.24Mo gzip 1.61Mo 0.72s lzo 1.75Mo 0.48s So for a compression ratio that is still relatively close to gzip, it's much faster to extract, at least in that case. This part contains: - Makefile routine to support lzo compression - Fixes to the existing lzo compressor so that it can be used in compressed kernels - wrapper around the existing lzo1x_decompress, as it only extracts one block at a time, while we need to extract a whole file here - config dialog for kernel compression Signed-off-by:
-
- 13 Nov, 2009 3 commits
-
-
Andrew Morton authored
#90: FILE: lib/zlib_inflate/inffast.c:250: + /* minimum length is three */$ ERROR: space prohibited before that close parenthesis ')' #97: FILE: lib/zlib_inflate/inffast.c:257: + if (dist > 2 ) { WARNING: suspect code indent for conditional statements (24, 28) #111: FILE: lib/zlib_inflate/inffast.c:271: + if (dist == 1) [...] + pat16 = (pat16 & 0xff) | ((pat16 & 0xff ) << 8); ERROR: space prohibited before that close parenthesis ')' #113: FILE: lib/zlib_inflate/inffast.c:273: + pat16 = (pat16 & 0xff) | ((pat16 & 0xff ) << 8); ERROR: space prohibited before that close parenthesis ')' #115: FILE: lib/zlib_inflate/inffast.c:275: + pat16 = (pat16 & 0xff00) | ((pat16 & 0xff00 ) >> 8); total: 4 errors, 1 warnings, 93 lines checked ./patches/zlib-optimize-inffast-when-copying-direct-from-output.patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by: -
Joakim Tjernlund authored
direct from output" case. This patch tries to optimize the direct copy procedure. Uses get_unaligned() but only in one place. The copy loop just above this one can also use this optimization, but I havn't done so as I have not tested if it is a win there too. On my MPC8321 this is about 17% faster on my JFFS2 root FS than the original. Signed-off-by:
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Cc: Roel Kluin <roel.kluin@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Akinobu Mita authored
Signed-off-by:
Anders Larsen <al@alarsen.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
- 10 Oct, 2009 1 commit
-
-
Anders Larsen authored
commit 945ffe54 ("qnx4: remove write support") removed the (defunct) write support but missed a chunk of related, dead code. Signed-off-by:
-
- 12 Nov, 2009 1 commit
-
-
Jean Delvare authored
parameter can be marked const. Same for resource_type(). Signed-off-by:
Jean Delvare <khali@linux-fr.org> Reviewed-by:
WANG Cong <xiyou.wangcong@gmail.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
- 10 Nov, 2009 2 commits
-
-
Andrew Morton authored
#252: FILE: fs/direct-io.c:1212: + if (end > isize ) total: 1 errors, 0 warnings, 338 lines checked ./patches/direct-io-cleanup-blockdev_direct_io-locking.patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: -
Christoph Hellwig authored
different locking types and very confusing checks for some of them. The most complicated one is DIO_OWN_LOCKING for reads, which happens to not actually be used. This patch gets rid of the DIO_OWN_LOCKING - as mentioned above the read case is unused anyway, and the write side is almost identical to DIO_NO_LOCKING. The difference is that DIO_NO_LOCKING always sets the create argument for the get_blocks callback to zero, but we can easily move that to the actual get_blocks callbacks. There are four users of the DIO_NO_LOCKING mode: gfs already ignores the create argument and thus is fine with the new version, ocfs2 only errors out if create were ever set, and we can remove this dead code now, the block device code only ever uses create for an error message if we are fully beyond the device which can never happen, and last but not least XFS will need the new behavour for writes. Now we can replace the lock_type variable with a flags one, where no flag means the DIO_NO_LOCKING behaviour and DIO_LOCKING is kept as the first flag. Separate out the check for not allowing to fill holes into a separate flag, although for now both flags always get set at the same time. Also revamp the documentation of the locking scheme to actually make sense. Signed-off-by:
Christoph Hellwig <hch@lst.de> Cc: Dave Chinner <david@fromorbit.com> Cc: Badari Pulavarty <pbadari@us.ibm.com> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Zach Brown <zach.brown@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Alex Elder <aelder@sgi.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <joel.becker@oracle.com> Signed-off-by:
-
- 30 Oct, 2009 2 commits
-
-
Andrew Morton authored
Cc: Zach Brown <zach.brown@oracle.com> Signed-off-by: -
Jeff Moyer authored
commit 848c4dd5 Author: Zach Brown <zach.brown@oracle.com> Date: Mon Aug 20 17:12:01 2007 -0700 dio: zero struct dio with kzalloc instead of manually This patch uses kzalloc to zero all of struct dio rather than manually trying to track which fields we rely on being zero. It passed aio+dio stress testing and some bug regression testing on ext3. This patch was introduced by Linus in the conversation that lead up to Badari's minimal fix to manually zero .map_bh.b_state in commit: 6a648fa7 It makes the code a bit smaller. Maybe a couple fewer cachelines to load, if we're lucky: text data bss dec hex filename 3285925 568506 1304616 5159047 4eb887 vmlinux 3285797 568506 1304616 5158919 4eb807 vmlinux.patched I was unable to measure a stable difference in the number of cpu cycles spent in blockdev_direct_IO() when pushing aio+dio 256K reads at ~340MB/s. So the resulting intent of the patch isn't a performance gain but to avoid exposing ourselves to the risk of finding another field like .map_bh.b_state where we rely on zeroing but don't enforce it in the code. Zach surmised that zeroing out the page array was what caused most of the problem, and suggested the approach taken in the attached patch for resolving the issue. Intel re-tested with this patch and saw a 0.6% performance gain (the original regression was 0.5%). Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Acked-by:
Zach Brown <zach.brown@oracle.com> Signed-off-by:
-
- 13 Nov, 2009 2 commits
-
-
Shaohua Li authored
Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Benjamin LaHaise <bcrl@kvack.org> Cc: Zach Brown <zach.brown@oracle.com> Signed-off-by:
-
Joe Perches authored
Acked-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
- 14 Oct, 2009 1 commit
-
-
Roel Kluin authored
Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
- 11 Nov, 2009 1 commit
-
-
Jan Beulich authored
comparison msut also be done using the last valid of the buffer in question. Also fix the open-coded instances in lib/swiotlb.c. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Becky Bruce <beckyb@kernel.crashing.org> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
- 30 Sep, 2009 3 commits
-
-
Nils Carlson authored
the patch as far as possible with correctible errors and things appear good. The DIMM mapping is correct for our board, but boards may differ. Signed-off-by:
Nils Carlson <nils.carlson@ludd.ltu.se> Acked-by:
Arthur Jones <ajones@riverbed.com> Signed-off-by:
Doug Thompson <dougthompson@xmission.com> Signed-off-by:
-
Nils Carlson authored
scrubbing rate, which is not constant but dependent on memory load. The rate returned by this driver is an estimate based on some experimentation, but is substantially closer to the truth than the speed supplied in the documentation. Also, scrubbing is done once, and then a done-bit is set. This means that to accomplish continuous scrubbing a re-enabling mechanism must be used. I have created the simplest possible such mechanism in the form of a work-queue which will check every five minutes. This interval is quite arbitrary but should be sufficient for all sizes of system memory. Signed-off-by:
-
Nils Carlson authored
places, this is simply a cleanup of the patch. Signed-off-by:
-
- 13 Nov, 2009 2 commits
-
-
Karel Zak authored
allocated for the header. The HeaderSize field must be greater than 92 (= sizeof(struct gpt_header) and must be less than or equal to the logical block size. It means we have to read whole sector with the header, because the header crc32 checksum is calculated according to HeaderSize. For more details see UEFI standard (version 2.3, May 2009): - 5.3.1 GUID Format overview, page 93 - Table 13. GUID Partition Table Header, page 96 Signed-off-by:
Karel Zak <kzak@redhat.com> Cc: Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Karel Zak authored
That's wrong. UEFI standard (version 2.3, May 2009, 5.3.1 GUID Format overview, page 95) defines that LBA is always based on the logical block size. It means bdev_logical_block_size() (aka BLKSSZGET) for Linux. This patch removes static sector size from EFI GPT parser. The problem is reproducible with the latest GNU Parted: # modprobe scsi_debug dev_size_mb=50 sector_size=4096 # ./parted /dev/sdb print Model: Linux scsi_debug (scsi) Disk /dev/sdb: 52.4MB Sector size (logical/physical): 4096B/4096B Partition Table: gpt Number Start End Size File system Name Flags 1 24.6kB 3002kB 2978kB primary 2 3002kB 6001kB 2998kB primary 3 6001kB 9003kB 3002kB primary # blockdev --rereadpt /dev/sdb # dmesg | tail -1 sdb: unknown partition table <---- !!! with this patch: # blockdev --rereadpt /dev/sdb # dmesg | tail -1 sdb: sdb1 sdb2 sdb3 Signed-off-by:
-
- 12 Nov, 2009 1 commit
-
-
Rakib Mullick authored
!MODULE. So, #ifdef MODULE becomes obsolete. Also move the declaration moxa_board_conf at the start of the function, since we were hit by the following warning. drivers/char/moxa.c: In function `moxa_init': drivers/char/moxa.c:1040: warning: ISO C90 forbids mixed declarations and code Signed-off-by: Rakib Mullick<rakib.mullick@gmail.com> Cc: Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
- 16 Oct, 2009 1 commit
-
-
Roel Kluin authored
Signed-off-by:
-
- 09 Oct, 2009 1 commit
-
-
Joe Perches authored
Convert printks to pr_<level> Convert some embedded function names to %s...__func__ Remove a period after exclamation points. Remove #define pr_dbg which could be used by future kernel.h includes Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
- 30 Sep, 2009 1 commit
-
-
Jiri Slaby authored
tty is dereferenced earlier, the test is superfluous. Remove it. Signed-off-by:
-
- 24 Aug, 2009 1 commit
-
-
Bartlomiej Zolnierkiewicz authored
Signed-off-by:
-
- 11 Nov, 2009 1 commit
-
-
Christoph Hellwig authored
USE_ELF_CORE_DUMP. The microblaze omission seems like an error to me, so let's kill this ifdef and make sure we are the same everywhere. Signed-off-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Cc: <linux-arch@vger.kernel.org> Cc: Michal Simek <michal.simek@petalogix.com> Signed-off-by:
-
- 29 Sep, 2009 1 commit
-
-
Julia Lawall authored
constants ending in _STATE are compared to the state variable. Signed-off-by:
Julia Lawall <julia@diku.dk> Cc: Corey Minyard <minyard@acm.org> Signed-off-by:
-
- 11 Nov, 2009 5 commits
-
-
Manfred Spraul authored
current code scans all decrement operations, even if the semaphore value is already 0. The patch optimizes that: if the semaphore value is 0, then there is no need to scan the q->alter entries. Note that this is a common case: It happens if 100 decrements by one are pending and now an increment by one increases the semaphore value from 0 to 1. Without this patch, all 100 entries are scanned. With the patch, only one entry is scanned, then woken up. Then the new rule triggers and the scanning is aborted, without looking at the remaining 99 tasks. With this patch, single sop increment/decrement by 1 are now O(1). (same as with Nick's patch) Signed-off-by:
Manfred Spraul <manfred@colorfullife.com> Cc: Nick Piggin <npiggin@suse.de> Cc: Pierre Peiffer <peifferp@gmail.com> Signed-off-by:
-
Manfred Spraul authored
semaphores. Atomic operations that affect multiple semaphores are supported. The patch optimizes single semaphore operation calls that affect only one semaphore: It's not necessary to scan all pending operations, it is sufficient to scan the per-semaphore list. The idea is from Nick Piggin version of an ipc sem improvement, the implementation is different: The code tries to keep as much common code as possible. As the result, the patch is simpler, but optimizes fewer cases. Signed-off-by:
-
Manfred Spraul authored
sysv sem has the concept of semaphore arrays that consist out of multiple semaphores. Atomic operations that affect multiple semaphores are supported. The patch is the first step for optimizing simple, single semaphore operations: In addition to the global list of all pending operations, a 2nd, per-semaphore list with the simple operations is added. Note: this patch does not make sense by itself, the new list is used nowhere. Signed-off-by:
-
Manfred Spraul authored
If try_atomic_semop failed, then no changes were applied. Thus no need to restart. Additionally, this patch correct an incorrect comment: It's possible to wait for arbitrary semaphore values (do a dec by <x>, wait-for-zero, inc by <x> in one atomic operation) Both changes are from Nick Piggin, the patch is the result of a different split of the individual changes. Signed-off-by:
-
Nick Piggin authored
involved, which could deadlock if preemption is enabled during the "lock". It is an implementation detail (due to a spinlock being held) that this is actually the case. However if "spinlocks" are made preemptible, or if the sem lock is changed to a sleeping lock for example, then the wakeup would become buggy. So this might be a bugfix for -rt kernels. Imagine waker being preempted by wakee and never clearing IN_WAKEUP -- if wakee has higher RT priority then there is a priority inversion deadlock. Even if there is not a priority inversion to cause a deadlock, then there is still time wasted spinning. Signed-off-by:
Nick Piggin <npiggin@suse.de> Signed-off-by:
-
