Re: video breaks asus-laptop display switching
On Sat, 2007-12-22 at 06:36 +0800, Andrei Gaponenko wrote: > > Hi, > > With 2.6.23 or newer (including 2.6.24-rc6) kernels, writing to the > /sys/devices/platform/asus-laptop/display file does not do anything: > > Cold boot to single user, then connect an external monitor > > # cat /sys/devices/platform/asus-laptop/display > 1 > > OK, only the built in LCD is enabled. Try to enable > the external monitor as well: > > # echo 3 > /sys/devices/platform/asus-laptop/display > > still no image on the external. > > # cat /sys/devices/platform/asus-laptop/display > 1 > > Still "1", not the "3" we wrote. On the other hand if I boot with an > external monitor attached, the "display" file always contains 3, even > after writing 1 there, and there is image on both monitors. > > In 2.6.22 I had to load asus-laptop by hand, but then display > switching worked nicely. > > I've noticed that if I do > > # rmmod video > > display switching starts working again with the newer kernels. > The "video" module was auto-loaded on my system in 2.6.22, but > did not cause the conflict. hmm, please "echo 1 > /proc/acpi/video/xxx/DOS" in 2.6.23 and see if there is any difference. Thansk, Rui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] Memory controller remove control_type feature
Andrew Morton wrote: > On Fri, 21 Dec 2007 00:23:58 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > >> Based on the discussion at http://lkml.org/lkml/2007/12/20/383, it was >> felt that control_type might not be a good thing to implement right away. >> We can add this flexibility at a later point when required. > > Gee the memory controller patchset is turning into a mess. > Yes, the patchset has expanded and we have several useful bug fixes and cleanups and some new features. > memory-controller-add-documentation.patch > memcgroup-temporarily-revert-swapoff-mod.patch > memory-controller-resource-counters-v7.patch > memory-controller-containers-setup-v7.patch > memory-controller-accounting-setup-v7.patch > memory-controller-memory-accounting-v7.patch > memory-controller-memory-accounting-v7-move-page_assign_page_cgroup-to-vm_bug_on-in-free_hot_cold_page.patch > memory-controller-task-migration-v7.patch > memory-controller-add-per-container-lru-and-reclaim-v7.patch > memory-controller-add-per-container-lru-and-reclaim-v7-memcgroup-fix-try_to_free-order.patch > memory-controller-improve-user-interface.patch > memory-controller-improve-user-interface-memory-controller-enhancements-for-reclaiming-take2-possible-race-fix-in-res_counter.patch > memory-controller-oom-handling-v7.patch > memory-controller-add-switch-to-control-what-type-of-pages-to-limit-v7.patch > memory-controller-make-page_referenced-container-aware-v7.patch > memory-controller-make-charging-gfp-mask-aware.patch > memory-controller-make-charging-gfp-mask-aware-fix.patch > memcgroup-reinstate-swapoff-mod.patch > memory-controller-bug_on.patch > mem-controller-gfp-mask-fix.patch > memcontrol-move-mm_cgroup-to-header-file.patch > memcontrol-move-oom-task-exclusion-to-tasklist.patch > oom-add-sysctl-to-enable-task-memory-dump.patch > kswapd-should-only-wait-on-io-if-there-is-io.patch > bugfix-for-memory-cgroup-controller-charge-refcnt-race-fix.patch > bugfix-for-memory-cgroup-controller-fix-error-handling-path-in-mem_charge_cgroup.patch > bugfix-for-memory-controller-add-helper-function-for-assigning-cgroup-to-page.patch > bugfix-for-memory-cgroup-controller-avoid-pagelru-page-in-mem_cgroup_isolate_pages.patch > bugfix-for-memory-cgroup-controller-avoid-pagelru-page-in-mem_cgroup_isolate_pages-fix.patch > memcgroup-fix-zone-isolation-oom.patch > memcgroup-revert-swap_state-mods.patch > bugfix-for-memory-cgroup-controller-migration-under-memory-controller-fix.patch > # > memory-cgroup-enhancements-fix-zone-handling-in-try_to_free_mem_cgroup_page.patch > memory-cgroup-enhancements-fix-zone-handling-in-try_to_free_mem_cgroup_page-warning-fix.patch > memory-cgroup-enhancements-force_empty-interface-for-dropping-all-account-in-empty-cgroup.patch > memory-cgroup-enhancements-remember-a-page-is-charged-as-page-cache.patch > memory-controller-use-rcu_read_lock-in-mem_cgroup_cache_charge.patch > memcgroup-tidy-up-mem_cgroup_charge_common.patch > memcgroup-fix-hang-with-shmem-tmpfs.patch > memory-cgroup-enhancements-remember-a-page-is-on-active-list-of-cgroup-or-not.patch > memory-cgroup-enhancements-add-status-accounting-function-for-memory-cgroup.patch > memory-cgroup-enhancements-add-status-accounting-function-for-memory-cgroup-checkpatch-fixes.patch > memory-cgroup-enhancements-add-status-accounting-function-for-memory-cgroup-fix-1.patch > memory-cgroup-enhancements-add-status-accounting-function-for-memory-cgroup-uninlining.patch > memory-cgroup-enhancements-add-status-accounting-function-for-memory-cgroup-fix-2.patch > memory-cgroup-enhancements-add-memorystat-file.patch > memory-cgroup-enhancements-add-memorystat-file-checkpatch-fixes.patch > memory-cgroup-enhancements-add-memorystat-file-printk-fix.patch > memory-cgroup-enhancements-add-pre_destroy-handler.patch > memory-cgroup-enhancements-implicit-force_empty-at-rmdir.patch > # > per-zone-and-reclaim-enhancements-for-memory-controller-take-3-add-scan_global_lru-macro.patch > per-zone-and-reclaim-enhancements-for-memory-controller-take-3-nid-zid-helper-function-for-cgroup.patch > per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-active-inactive-counter.patch > per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-active-inactive-counter-memory-controller-enhancements-for-reclaiming-take2-clean-up-remove-unused-variable.patch > per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-active-inactive-counter-memory-controller-enhancements-for-reclaiming-take2-add-bug_on-in-mem_cgroup_zoneinfo.patch > per-zone-and-reclaim-enhancements-for-memory-controller-take-3-calculate-mapper_ratio-per-cgroup.patch > per-zone-and-reclaim-enhancements-for-memory-controller-take-3-calculate-active-inactive-imbalance-per-cgroup.patch > per-zone-and-reclaim-enhancements-for-memory-controller-take-3-remember-reclaim-priority-in-memory-cgroup.patch >
Re: [RFC] USB Kconfig: Declutter USB Kconfig Menu
> > Which is why my suggestion was to have them both move up a level, with > > host and peripheral side menus nested normally: > > > > Device Drivers: > > ... > > [ ] HID devices > > < > Host side USB > > < > Peripheral side USB > > < > MMC/SD/SDIO card support > > [ ] LED support > > ... > > > > That way both host and peripheral side support would have their own > > menu, and that pointless nesting would be reduced. > > You mean: > [ ] Host side USB > [ ] Peripheral side USB > > Right? Both of those subsystems are already set up with the main choice as tristate "< >//<*>". If we're simplifying the navigation, I can't see a point to requiring *two* menu actions not one. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] Remove lib/inflate.c
Signed-off-by: Joe Perches <[EMAIL PROTECTED]> --- lib/inflate.c | 1265 - 1 files changed, 0 insertions(+), 1265 deletions(-) delete mode 100644 lib/inflate.c diff --git a/lib/inflate.c b/lib/inflate.c deleted file mode 100644 index 845f91d..000 --- a/lib/inflate.c +++ /dev/null @@ -1,1265 +0,0 @@ -#define DEBG(x) -#define DEBG1(x) -/* inflate.c -- Not copyrighted 1992 by Mark Adler - version c10p1, 10 January 1993 */ - -/* - * Adapted for booting Linux by Hannu Savolainen 1993 - * based on gzip-1.0.3 - * - * Nicolas Pitre <[EMAIL PROTECTED]>, 1999/04/14 : - * Little mods for all variable to reside either into rodata or bss segments - * by marking constant variables with 'const' and initializing all the others - * at run-time only. This allows for the kernel uncompressor to run - * directly from Flash or ROM memory on embedded systems. - */ - -/* - Inflate deflated (PKZIP's method 8 compressed) data. The compression - method searches for as much of the current string of bytes (up to a - length of 258) in the previous 32 K bytes. If it doesn't find any - matches (of at least length 3), it codes the next byte. Otherwise, it - codes the length of the matched string and its distance backwards from - the current position. There is a single Huffman code that codes both - single bytes (called "literals") and match lengths. A second Huffman - code codes the distance information, which follows a length code. Each - length or distance code actually represents a base value and a number - of "extra" (sometimes zero) bits to get to add to the base value. At - the end of each deflated block is a special end-of-block (EOB) literal/ - length code. The decoding process is basically: get a literal/length - code; if EOB then done; if a literal, emit the decoded byte; if a - length then get the distance and emit the referred-to bytes from the - sliding window of previously emitted data. - - There are (currently) three kinds of inflate blocks: stored, fixed, and - dynamic. The compressor deals with some chunk of data at a time, and - decides which method to use on a chunk-by-chunk basis. A chunk might - typically be 32 K or 64 K. If the chunk is incompressible, then the - "stored" method is used. In this case, the bytes are simply stored as - is, eight bits per byte, with none of the above coding. The bytes are - preceded by a count, since there is no longer an EOB code. - - If the data is compressible, then either the fixed or dynamic methods - are used. In the dynamic method, the compressed data is preceded by - an encoding of the literal/length and distance Huffman codes that are - to be used to decode this block. The representation is itself Huffman - coded, and so is preceded by a description of that code. These code - descriptions take up a little space, and so for small blocks, there is - a predefined set of codes, called the fixed codes. The fixed method is - used if the block codes up smaller that way (usually for quite small - chunks), otherwise the dynamic method is used. In the latter case, the - codes are customized to the probabilities in the current block, and so - can code it much better than the pre-determined fixed codes. - - The Huffman codes themselves are decoded using a multi-level table - lookup, in order to maximize the speed of decoding plus the speed of - building the decoding tables. See the comments below that precede the - lbits and dbits tuning parameters. - */ - - -/* - Notes beyond the 1.93a appnote.txt: - - 1. Distance pointers never point before the beginning of the output - stream. - 2. Distance pointers can point back across blocks, up to 32k away. - 3. There is an implied maximum of 7 bits for the bit length table and - 15 bits for the actual data. - 4. If only one code exists, then it is encoded using one bit. (Zero - would be more efficient, but perhaps a little confusing.) If two - codes exist, they are coded using one bit each (0 and 1). - 5. There is no way of sending zero distance codes--a dummy must be - sent if there are none. (History: a pre 2.0 version of PKZIP would - store blocks with no distance codes, but this was discovered to be - too harsh a criterion.) Valid only for 1.93a. 2.04c does allow - zero distance codes, which is sent as one code of zero bits in - length. - 6. There are up to 286 literal/length codes. Code 256 represents the - end-of-block. Note however that the static length tree defines - 288 codes just to fill out the Huffman codes. Codes 286 and 287 - cannot be used though, since there is no length base or extra bits - defined for them. Similarly, there are up to 30 distance codes. - However, static trees define 32 codes (all 5 bits) to fill out the - Huffman codes, but the last two had better
[PATCH 2/3] Remove unused dependency
Signed-off-by: Joe Perches <[EMAIL PROTECTED]> --- arch/arm/boot/compressed/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/boot/compressed/Makefile b/arch/arm/boot/compressed/Makefile index 5fde99f..563cfc2 100644 --- a/arch/arm/boot/compressed/Makefile +++ b/arch/arm/boot/compressed/Makefile @@ -111,5 +111,5 @@ $(obj)/font.c: $(FONTC) $(obj)/vmlinux.lds: $(obj)/vmlinux.lds.in arch/arm/boot/Makefile .config @sed "$(SEDFLAGS)" < $< > $@ -$(obj)/misc.o: $(obj)/misc.c include/asm/arch/uncompress.h lib/inflate.c +$(obj)/misc.o: $(obj)/misc.c include/asm/arch/uncompress.h -- 1.5.3.7.949.g2221a6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Remove lib/inflate.c
Uncompiled/Untested (no cross-compiler for alpha) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Remove unused dependency
Signed-off-by: Joe Perches <[EMAIL PROTECTED]> --- arch/alpha/boot/Makefile |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/alpha/boot/Makefile b/arch/alpha/boot/Makefile index cd14388..c53169c 100644 --- a/arch/alpha/boot/Makefile +++ b/arch/alpha/boot/Makefile @@ -112,5 +112,3 @@ $(obj)/bootpheader: $(obj)/bootloader.lds $(OBJ_bootph) $(LIBS_Y) FORCE $(obj)/bootpzheader: $(obj)/bootloader.lds $(OBJ_bootpzh) $(LIBS_Y) FORCE $(call if_changed,ld) - -$(obj)/misc.o: lib/inflate.c -- 1.5.3.7.949.g2221a6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] Memory controller remove control_type feature
On Fri, 21 Dec 2007 00:23:58 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > Based on the discussion at http://lkml.org/lkml/2007/12/20/383, it was > felt that control_type might not be a good thing to implement right away. > We can add this flexibility at a later point when required. Gee the memory controller patchset is turning into a mess. memory-controller-add-documentation.patch memcgroup-temporarily-revert-swapoff-mod.patch memory-controller-resource-counters-v7.patch memory-controller-containers-setup-v7.patch memory-controller-accounting-setup-v7.patch memory-controller-memory-accounting-v7.patch memory-controller-memory-accounting-v7-move-page_assign_page_cgroup-to-vm_bug_on-in-free_hot_cold_page.patch memory-controller-task-migration-v7.patch memory-controller-add-per-container-lru-and-reclaim-v7.patch memory-controller-add-per-container-lru-and-reclaim-v7-memcgroup-fix-try_to_free-order.patch memory-controller-improve-user-interface.patch memory-controller-improve-user-interface-memory-controller-enhancements-for-reclaiming-take2-possible-race-fix-in-res_counter.patch memory-controller-oom-handling-v7.patch memory-controller-add-switch-to-control-what-type-of-pages-to-limit-v7.patch memory-controller-make-page_referenced-container-aware-v7.patch memory-controller-make-charging-gfp-mask-aware.patch memory-controller-make-charging-gfp-mask-aware-fix.patch memcgroup-reinstate-swapoff-mod.patch memory-controller-bug_on.patch mem-controller-gfp-mask-fix.patch memcontrol-move-mm_cgroup-to-header-file.patch memcontrol-move-oom-task-exclusion-to-tasklist.patch oom-add-sysctl-to-enable-task-memory-dump.patch kswapd-should-only-wait-on-io-if-there-is-io.patch bugfix-for-memory-cgroup-controller-charge-refcnt-race-fix.patch bugfix-for-memory-cgroup-controller-fix-error-handling-path-in-mem_charge_cgroup.patch bugfix-for-memory-controller-add-helper-function-for-assigning-cgroup-to-page.patch bugfix-for-memory-cgroup-controller-avoid-pagelru-page-in-mem_cgroup_isolate_pages.patch bugfix-for-memory-cgroup-controller-avoid-pagelru-page-in-mem_cgroup_isolate_pages-fix.patch memcgroup-fix-zone-isolation-oom.patch memcgroup-revert-swap_state-mods.patch bugfix-for-memory-cgroup-controller-migration-under-memory-controller-fix.patch # memory-cgroup-enhancements-fix-zone-handling-in-try_to_free_mem_cgroup_page.patch memory-cgroup-enhancements-fix-zone-handling-in-try_to_free_mem_cgroup_page-warning-fix.patch memory-cgroup-enhancements-force_empty-interface-for-dropping-all-account-in-empty-cgroup.patch memory-cgroup-enhancements-remember-a-page-is-charged-as-page-cache.patch memory-controller-use-rcu_read_lock-in-mem_cgroup_cache_charge.patch memcgroup-tidy-up-mem_cgroup_charge_common.patch memcgroup-fix-hang-with-shmem-tmpfs.patch memory-cgroup-enhancements-remember-a-page-is-on-active-list-of-cgroup-or-not.patch memory-cgroup-enhancements-add-status-accounting-function-for-memory-cgroup.patch memory-cgroup-enhancements-add-status-accounting-function-for-memory-cgroup-checkpatch-fixes.patch memory-cgroup-enhancements-add-status-accounting-function-for-memory-cgroup-fix-1.patch memory-cgroup-enhancements-add-status-accounting-function-for-memory-cgroup-uninlining.patch memory-cgroup-enhancements-add-status-accounting-function-for-memory-cgroup-fix-2.patch memory-cgroup-enhancements-add-memorystat-file.patch memory-cgroup-enhancements-add-memorystat-file-checkpatch-fixes.patch memory-cgroup-enhancements-add-memorystat-file-printk-fix.patch memory-cgroup-enhancements-add-pre_destroy-handler.patch memory-cgroup-enhancements-implicit-force_empty-at-rmdir.patch # per-zone-and-reclaim-enhancements-for-memory-controller-take-3-add-scan_global_lru-macro.patch per-zone-and-reclaim-enhancements-for-memory-controller-take-3-nid-zid-helper-function-for-cgroup.patch per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-active-inactive-counter.patch per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-active-inactive-counter-memory-controller-enhancements-for-reclaiming-take2-clean-up-remove-unused-variable.patch per-zone-and-reclaim-enhancements-for-memory-controller-take-3-per-zone-active-inactive-counter-memory-controller-enhancements-for-reclaiming-take2-add-bug_on-in-mem_cgroup_zoneinfo.patch per-zone-and-reclaim-enhancements-for-memory-controller-take-3-calculate-mapper_ratio-per-cgroup.patch per-zone-and-reclaim-enhancements-for-memory-controller-take-3-calculate-active-inactive-imbalance-per-cgroup.patch per-zone-and-reclaim-enhancements-for-memory-controller-take-3-remember-reclaim-priority-in-memory-cgroup.patch per-zone-and-reclaim-enhancements-for-memory-controller-take-3-remember-reclaim-priority-in-memory-cgroup-fix.patch per-zone-and-reclaim-enhancements-for-memory-controller-take-3-remember-reclaim-priority-in-memory-cgroup-fix-2.patch per-zone-and-reclaim-enhancements-for-memory-controller-take-3-calculate-the-number-of-pages-to-be-scanned-per-cgroup.patch
Re: [RFC] USB Kconfig: Declutter USB Kconfig Menu
David Brownell wrote: > > > The driver stacks are independent of each other, except for common > > > data structures like what's in the header file. I > > > think there's no real point, other than history, to having both sides > > > share the same menu. > > > > They aren't. > > How can you say that, when you showed (right above!!) that they are??? > Sure, there are submenus too. But they're clearly in the same menu. Well, in that case even if you moved them to the upper level, then they would still be in the same menu, if that's what you mean. > > USB Gadget Support is in its own sub-menu. And strictly > > speaking, Host-side USB should be too, but some people may feel that > > this would be nesting it too deep, and so it unfolds in the same menu. > > Which is why my suggestion was to have them both move up a level, with > host and peripheral side menus nested normally: > > Device Drivers: > ... > [ ] HID devices > < > Host side USB > < > Peripheral side USB > < > MMC/SD/SDIO card support > [ ] LED support > ... > > That way both host and peripheral side support would have their own > menu, and that pointless nesting would be reduced. You mean: [ ] Host side USB [ ] Peripheral side USB Right? All this does is loose the USB menu, which was used to group them and to un-clutter the Device Drivers menu. Note: They would still be sharing the same menu, only this time it's the Device Drivers menu. I guess it's a judgment call. Let's see what others think. Thanks! -- Al -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tty: Fix logic change introduced by wait_event_interruptible_timeout()
On Thu, 20 Dec 2007 16:39:21 -0500 "Cory T. Tusar" <[EMAIL PROTECTED]> wrote:
> tty: Fix logic change introduced by wait_event_interruptible_timeout()
>
> Commit 5a52bd4a2dcb570333ce6fe2e16cd311650dbdc8 introduced a subtle logic
> change in tty_wait_until_sent(). The original version would only error
> out of the 'do { ... } while (timeout)' loop if signal_pending() evaluated
> to true; a timeout or break due to an empty buffer would fall out of the
> loop and into the tty->driver->wait_until_sent handling. The current
> implementation will error out on either a pending signal or an empty
> buffer, falling through to the tty->driver->wait_until_sent handling
> only on a timeout.
>
> This change reverts the logic flow in tty_wait_until_sent() to match that
> prior to the aforementioned commit.
>
> Signed-off-by: Cory T. Tusar <[EMAIL PROTECTED]>
>
> ---
> Please CC me on any replies; I'm not subscribed to lkml. Thanks.
>
> drivers/char/tty_ioctl.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/char/tty_ioctl.c b/drivers/char/tty_ioctl.c
> index 1bdd2bf..e02d592 100644
> --- a/drivers/char/tty_ioctl.c
> +++ b/drivers/char/tty_ioctl.c
> @@ -62,7 +62,7 @@ void tty_wait_until_sent(struct tty_struct * tty, long
> timeout)
> if (!timeout)
> timeout = MAX_SCHEDULE_TIMEOUT;
> if (wait_event_interruptible_timeout(tty->write_wait,
> - !tty->driver->chars_in_buffer(tty), timeout))
> + !tty->driver->chars_in_buffer(tty), timeout) < 0)
> return;
> if (tty->driver->wait_until_sent)
> tty->driver->wait_until_sent(tty, timeout);
>
>
OK... So what are the user-visible effects of this regression? The caller
will run ->wait_until_sent() even after being signalled? So the signal is
not promptly responded to?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] usb: libusual: locking cleanup
On Fri, 21 Dec 2007 22:24:28 -0800 Pete Zaitcev <[EMAIL PROTECTED]> wrote: > On Fri, 21 Dec 2007 00:00:04 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote: > > > I converted the usu_init_notify semaphore to normal mutex usage, and it > > should still prevent the request_module before the init routine is > > complete. Before it acted more like a complete, now the mutex protects > > two distinct section from running at the same time.. > > Let's see. > > > @@ -178,10 +179,7 @@ static int usu_probe_thread(void *arg) > > int rc; > > unsigned long flags; > > > > - /* A completion does not work here because it's counted. */ > > - down(_init_notify); > > - up(_init_notify); > > - > > + mutex_lock(_probe_mutex); > > rc = request_module(bias_names[type]); > > When I tried it, usb-storage would not load with unresolved symbols. > It happens if child (usu_probe_thread) runs ahead of its parent > (usb_usual_init -> usb_register -> usu_probe). It's entirely possible, > depending on your scheduler. afaict Daniel's change will fix that? He releases usu_probe_mutex once the usb_register() has completed and this then allows the usb_probe_thread() to start working. I'm still wondering if that theory has been tested though. > I hate this down-up trick too I'd be worried if you were proud of it ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] usb: libusual: locking cleanup
On Fri, 21 Dec 2007 00:00:04 -0800, Daniel Walker <[EMAIL PROTECTED]> wrote: > I converted the usu_init_notify semaphore to normal mutex usage, and it > should still prevent the request_module before the init routine is > complete. Before it acted more like a complete, now the mutex protects > two distinct section from running at the same time.. Let's see. > @@ -178,10 +179,7 @@ static int usu_probe_thread(void *arg) > int rc; > unsigned long flags; > > - /* A completion does not work here because it's counted. */ > - down(_init_notify); > - up(_init_notify); > - > + mutex_lock(_probe_mutex); > rc = request_module(bias_names[type]); When I tried it, usb-storage would not load with unresolved symbols. It happens if child (usu_probe_thread) runs ahead of its parent (usb_usual_init -> usb_register -> usu_probe). It's entirely possible, depending on your scheduler. I hate this down-up trick too, so if you have a better idea, I'm all ears. -- Pete -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] USB Kconfig: Declutter USB Kconfig Menu
> > Notice that this whole menu is for "Host-side USB", except for that > > gadget stuff. That might usefully be labeled as "Peripheral-side USB". > > > > For that matter, it could be moved up a level in the menu, so the top > > level driver menu has two USB entries: Host side, and Peripheral side. > > Actually, when you disable Host-side USB support, the menu looks like this: > > ┌───???──???──???───┐ > │ --- USB support │ > │ < > Support for Host-side USB ---> │ > │ USB Gadget Support ---> │ > │ │ Right, that's what I said. It makes the gadget stuff needlessly hard to find, as well as being less clear about what a "gadget" is than it really should be. > I think renaming 'USB Gadget Support' to 'Support for Peripheral-side USB' is > probably a good idea. Only for displaying in its topmost menu... > > The driver stacks are independent of each other, except for common data > > structures like what's in the header file. I think > > there's no real point, other than history, to having both sides share > > the same menu. > > They aren't. How can you say that, when you showed (right above!!) that they are??? Sure, there are submenus too. But they're clearly in the same menu. > USB Gadget Support is in its own sub-menu. And strictly > speaking, Host-side USB should be too, but some people may feel that this > would be nesting it too deep, and so it unfolds in the same menu. Which is why my suggestion was to have them both move up a level, with host and peripheral side menus nested normally: Device Drivers: ... [ ] HID devices < > Host side USB < > Peripheral side USB < > MMC/SD/SDIO card support [ ] LED support ... That way both host and peripheral side support would have their own menu, and that pointless nesting would be reduced. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/13] update copyright date
On Thu, 20 Dec 2007 17:16:01 -0500 "Ed L. Cashin" <[EMAIL PROTECTED]> wrote:
> Subject: [PATCH 13/13] update copyright date
Please put an identfier for the subsytem in patch titles. In this case,
Subject: [PATCH 13/13] aoe: update copyright date
would suit.
I dropped aoe-remove-race-between-use-and-initialization-of-locks.patch,
queued the rest and added the below, thanks.
aoe: statically initialise devlist_lock
From: Andrew Morton <[EMAIL PROTECTED]>
I guess aoedev_init() can go away now.
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: "Ed L. Cashin" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/block/aoe/aoedev.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff -puN drivers/block/aoe/aoedev.c~aoe-statically-initialise-devlist_lock
drivers/block/aoe/aoedev.c
--- a/drivers/block/aoe/aoedev.c~aoe-statically-initialise-devlist_lock
+++ a/drivers/block/aoe/aoedev.c
@@ -16,7 +16,7 @@ static void freetgt(struct aoedev *d, st
static void skbpoolfree(struct aoedev *d);
static struct aoedev *devlist;
-static spinlock_t devlist_lock;
+static DEFINE_SPINLOCK(devlist_lock);
int
aoedev_isbusy(struct aoedev *d)
@@ -291,7 +291,5 @@ aoedev_exit(void)
int __init
aoedev_init(void)
{
- spin_lock_init(_lock);
return 0;
}
-
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/13] remove race between use and initialization of locks
On Thu, 20 Dec 2007 17:15:57 -0500 "Ed L. Cashin" <[EMAIL PROTECTED]> wrote:
> Alexey Dobriyan noticed a race in the initialization of the dynamic
> locks in ...
>
> Message-ID: <[EMAIL PROTECTED]>
>
> Andrew Morton commented that these locks should be initialized at
> compile time, so this patch does that.
>
> Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]>
> ---
> drivers/block/aoe/aoechr.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/block/aoe/aoechr.c b/drivers/block/aoe/aoechr.c
> index 1bc85aa..670bba6 100644
> --- a/drivers/block/aoe/aoechr.c
> +++ b/drivers/block/aoe/aoechr.c
> @@ -35,8 +35,8 @@ struct ErrMsg {
>
> static struct ErrMsg emsgs[NMSG];
> static int emsgs_head_idx, emsgs_tail_idx;
> -static struct semaphore emsgs_sema;
> -static spinlock_t emsgs_lock;
> +static __DECLARE_SEMAPHORE_GENERIC(emsgs_sema, 0);
That's not very attractive. This would be the only user of
__DECLARE_SEMAPHORE_GENERIC() in the tree. It seems that all architectures
(apart from uml) do implement this (although I didn't verify that they all
offer the same interface for it). But still...
And no, we don't appear to have a proper interface to statically declare a
locked semaphore. Nor do we appear to have one for mutexes(!).
> +static DEFINE_SPINLOCK(emsgs_lock);
> static int nblocked_emsgs_readers;
> static struct class *aoe_class;
> static struct aoe_chardev chardevs[] = {
> @@ -264,8 +264,6 @@ aoechr_init(void)
> printk(KERN_ERR "aoe: can't register char device\n");
> return n;
> }
> - sema_init(_sema, 0);
> - spin_lock_init(_lock);
> aoe_class = class_create(THIS_MODULE, "aoe");
> if (IS_ERR(aoe_class)) {
> unregister_chrdev(AOE_MAJOR, "aoechr");
I think it would be better to go back to initialising emsgs_lock at runtime
rather than fattening the exported semaphore API like this.
emssgs_sema is a weird-looking thing. There really should be some comments
in there because it is unobvious what the code is attempting to do.
What is the code attempting to do?
It appears to me that nblocked_emsgs_readers gets incorrectly decremented
if the down_interruptible() got interrupted, btw.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5]PCI: x86 MMCONFIG - a couple of corrections to the preamble
Some corrections to the preamble. The large amount of text is due to the nature of the problem and the discussion it engendered on the lkml. Should say: The large amount of text in the explanation below is due to the nature of the problem and the discussion engendered on lkml by my first submission. This patch-set detects the problem by comparing an MMCONFIG read to a Legacy PCI config read of the vendor/device dword of every device discovered during the PCI probing sequence. Actually, the patch doesn't do a pci config read of EVERY device discovered on every bus. Only on buses above a number defined by PCI_MMCFG_MAX_CHECK_BUS and whose parent bus's pci_bus.ops field points to pci_root_ops, which are mmconfig access routines in systems in which mmconfig is the default mechanism. In such cases where the parent bus pci_bus.ops field points to pci_legacy_ops, the current bus does not need to be probed, since its own pci_bus.ops field will inherit the pointer to pci_legacy_ops from its parent. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1: problems with cat /proc/kpageflags
On Fri, 21 Dec 2007 22:51:45 +0100 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote: > > Here's a test patch: > > Tested on 2.6.23 and 2.6.24-rc5-mm1. The patch fixes the bug. > > Thanks a lot to both of you. Thank you for testing -mm (especially on sparc64) and for reporting the bug and for testing the fix. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ecryptfs: check for existing key_tfm at mount time
On Thu, 20 Dec 2007 23:18:49 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Jeff Moyer pointed out that a mount; umount loop of ecryptfs,
> with the same cipher & other mount options, created a new
> ecryptfs_key_tfm_cache item each time, and the cache could
> grow quite large this way.
>
> Looking at this with mhalcrow, we saw that ecryptfs_parse_options()
> unconditionally called ecryptfs_add_new_key_tfm(), which is what
> was adding these items.
>
> Refactor ecryptfs_get_tfm_and_mutex_for_cipher_name() to create a
> new helper function, ecryptfs_tfm_exists(), which checks for the
> cipher on the cached key_tfm_list, and sets a pointer
> to it if it exists. This can then be called from
> ecryptfs_parse_options(), and new key_tfm's can be added only when
> a cached one is not found.
>
This change looks fishy.
> +/**
> + * ecryptfs_tfm_exists - Search for existing tfm for cipher_name.
> + * @cipher_name: the name of the cipher to search for
> + * @key_tfm: set to corresponding tfm if found
> + *
> + * Returns 1 if found, with key_tfm set
> + * Returns 0 if not found, key_tfm set to NULL
> + */
> +int ecryptfs_tfm_exists(char *cipher_name, struct ecryptfs_key_tfm **key_tfm)
> +{
> + struct ecryptfs_key_tfm *tmp_key_tfm;
> +
> + mutex_lock(_tfm_list_mutex);
> + list_for_each_entry(tmp_key_tfm, _tfm_list, key_tfm_list) {
> + if (strcmp(tmp_key_tfm->cipher_name, cipher_name) == 0) {
> + mutex_unlock(_tfm_list_mutex);
> + if (key_tfm)
> + (*key_tfm) = tmp_key_tfm;
Here we return a pointer to an object without holding the lock and without
taking a refcount on it. What prevents it from getting moved/freed/etc
while this thread of control is playing with it?
> + return 1;
> + }
> + }
> + mutex_unlock(_tfm_list_mutex);
> + if (key_tfm)
> + (*key_tfm) = NULL;
> + return 0;
> +}
> +
> int ecryptfs_get_tfm_and_mutex_for_cipher_name(struct crypto_blkcipher **tfm,
> struct mutex **tfm_mutex,
> char *cipher_name)
> @@ -1877,22 +1904,15 @@ int ecryptfs_get_tfm_and_mutex_for_ciphe
>
> (*tfm) = NULL;
> (*tfm_mutex) = NULL;
> - mutex_lock(_tfm_list_mutex);
> - list_for_each_entry(key_tfm, _tfm_list, key_tfm_list) {
> - if (strcmp(key_tfm->cipher_name, cipher_name) == 0) {
> - (*tfm) = key_tfm->key_tfm;
> - (*tfm_mutex) = _tfm->key_tfm_mutex;
> - mutex_unlock(_tfm_list_mutex);
> +
> + if (!ecryptfs_tfm_exists(cipher_name, _tfm)) {
And given that we've just unlocked key_tfm_list_mutex, how do we know that
the return value from ecryptfs_tfm_exists() is still true in this window?
> + rc = ecryptfs_add_new_key_tfm(_tfm, cipher_name, 0);
> + if (rc) {
> + printk(KERN_ERR "Error adding new key_tfm to list; "
> + "rc = [%d]\n", rc);
> goto out;
> }
> }
> - mutex_unlock(_tfm_list_mutex);
It would all look a lot more solid if this locking was retained and both
ecryptfs_tfm_exists() and ecryptfs_add_new_key_tfm() were designed to be
called under key_tfm_list_mutex.
> @@ -410,9 +410,11 @@ static int ecryptfs_parse_options(struct
> if (!cipher_key_bytes_set) {
> mount_crypt_stat->global_default_cipher_key_size = 0;
> }
> - rc = ecryptfs_add_new_key_tfm(
> - NULL, mount_crypt_stat->global_default_cipher_name,
> - mount_crypt_stat->global_default_cipher_key_size);
> + if (!ecryptfs_tfm_exists(mount_crypt_stat->global_default_cipher_name,
> + NULL))
> + rc = ecryptfs_add_new_key_tfm(
> + NULL, mount_crypt_stat->global_default_cipher_name,
> + mount_crypt_stat->global_default_cipher_key_size);
dittoes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: compat_sys_times() bogus until jiffies >= 0.
From: Andi Kleen <[EMAIL PROTECTED]> Date: Sat, 22 Dec 2007 02:53:11 +0100 > > And to handle potentially ambiguous cases we, for a long time, have > > the force_successful_syscall_return() arch hook. > > Ah I see what you mean now. > > Thanks for the clarification. Thanks for continuing to insist it's "impossible" :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] usb: libusual: locking cleanup
On Fri, 21 Dec 2007 00:00:04 -0800 Daniel Walker <[EMAIL PROTECTED]> wrote:
> I converted the usu_init_notify semaphore to normal mutex usage, and it
> should still prevent the request_module before the init routine is
> complete. Before it acted more like a complete, now the mutex protects
> two distinct section from running at the same time..
>
> Signed-off-by: Daniel Walker <[EMAIL PROTECTED]>
>
> ---
> drivers/usb/storage/libusual.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> Index: linux-2.6.23/drivers/usb/storage/libusual.c
> ===
> --- linux-2.6.23.orig/drivers/usb/storage/libusual.c
> +++ linux-2.6.23/drivers/usb/storage/libusual.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> */
> @@ -30,7 +31,7 @@ static atomic_t usu_bias = ATOMIC_INIT(U
> #define BIAS_NAME_SIZE (sizeof("usb-storage"))
> static const char *bias_names[3] = { "none", "usb-storage", "ub" };
>
> -static struct semaphore usu_init_notify;
> +static DEFINE_MUTEX(usu_probe_mutex);
> static DECLARE_COMPLETION(usu_end_notify);
> static atomic_t total_threads = ATOMIC_INIT(0);
>
> @@ -178,10 +179,7 @@ static int usu_probe_thread(void *arg)
> int rc;
> unsigned long flags;
>
> - /* A completion does not work here because it's counted. */
> - down(_init_notify);
> - up(_init_notify);
> -
> + mutex_lock(_probe_mutex);
> rc = request_module(bias_names[type]);
> spin_lock_irqsave(_lock, flags);
> if (rc == 0 && (st->fls & USU_MOD_FL_PRESENT) == 0) {
> @@ -194,6 +192,7 @@ static int usu_probe_thread(void *arg)
> }
> st->fls &= ~USU_MOD_FL_THREAD;
> spin_unlock_irqrestore(_lock, flags);
> + mutex_unlock(_probe_mutex);
>
> complete_and_exit(_end_notify, 0);
> }
> @@ -204,10 +203,9 @@ static int __init usb_usual_init(void)
> {
> int rc;
>
> - sema_init(_init_notify, 0);
> -
> + mutex_lock(_probe_mutex);
> rc = usb_register(_driver);
> - up(_init_notify);
> + mutex_unlock(_probe_mutex);
> return rc;
> }
That's some pretty hairy-looking code you're playing with there. Has this
been runtime tested?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: printf internals
Most likely your device nodes are missing in /dev. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Siva Prasad Sent: Thursday, December 20, 2007 4:03 AM To: Clemens Koller; David Newall Cc: linux-kernel@vger.kernel.org Subject: RE: printf internals Thank you very much for your response Clemens. I tried strace on a regular system. It does not show which tty, etc., as it uses the stdout (fd = 1) and write(1, ...) to it. This is not a student project. I am trying to build my own kernel and ramdisk. Kernel boots fine to a point where it starts accessing ramdisk and executes init scripts. From there on nothing gets printed. I did some debugging and found that prints of user land programs are not coming to the serial console, while kernel prints are working fine. I found all the programs getting executed, by placing a printk in execve routine and printing the arguments. So, I wanted to trace down the path from user program to the kernel and see why it is not printing messages from user program. I placed a printk in drivers/char/tty_io.c:tty_write() and it is not getting called from my file system. I tried the same thing on my good system (say regular PC) and it works as expected. Any clues that can help debug this issue is highly appreciated. How can I get access to the same printf string inside kernel. Thanks Siva -Original Message- From: Clemens Koller [mailto:[EMAIL PROTECTED] Sent: Friday, December 14, 2007 8:16 AM To: David Newall Cc: Siva Prasad; linux-kernel@vger.kernel.org Subject: Re: printf internals David Newall schrieb: > Siva Prasad wrote: >> I am looking at how exactly does the printf in user programs succeeds in >> displaying characters to the serial console. > > Is it a student assignment? This is so not the right mailing list. Come on, are we playing hide and seek here? You can use strace to follow a typical hello world example and see what device it opens to feed the hello out. I.e. it can be to the current /dev/ttyX and not to /dev/console or if you are logged in via SSH to a machine, the device is again different... or if you use screen, ... Work your way from there and then use a Linux Source code Cross Reference (lxr, ask Google for one) and follow the code. Regards, -- Clemens Koller __ R Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, Dec 21, 2007 at 08:19:42PM -0600, Matt Mackall wrote: > > On Sat, 2007-12-22 at 01:28 +0100, Andi Kleen wrote: > > Ingo Molnar <[EMAIL PROTECTED]> writes: > > > > > Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop > > > relies on it, people use it every day to monitor memory consumption. > > > > It's definitely not a stable ABI. slabtop tends to exit without any > > error message on any slabinfo version number increase and I've seen > > that happen several times in not so old kernels. > > > > Requiring just another slabtop update isn't really a big deal. > > Might as well mention that SLOB also doesn't provide this functionality, > nor would it make any sense for it to try (because there are no > slab-like objects to report about). % slabinfo Name Objects ObjsizeSpace Slabs/Part/Cpu O/S O %Fr %Ef Flg ... anon_vma 1551 2481.9K20/18/2 128 0 90 45 Seems certainly like information that slabtop could report, even if it's not exactly the same. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] be more verbose when probing EDD
On Fri, Dec 21, 2007 at 06:22:41PM -0800, H. Peter Anvin wrote: > >Ok, that's a different argument than before. Ok. Although it's > >only a few bytes. > > > >I would lobby for any message at least contain the suggestion to try > >edd=off. That could save users a lot of time. > > The important thing is that there is a message before and after. The > rest can be dealt with by Google on in documentation. That's what the That means every user needs to waste at least 5 minutes to google/read docs and be annoyed by someone's ads. Collective waste. Just adding "Try edd=off if this hangs" is ~23 bytes and adding that should be hardly a problem even in your 32k. Or perhaps if you're more worried about code size than grammer "edd=off when hang" @) -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] be more verbose when probing EDD
Andi Kleen wrote: Those don't live in an area of memory which is hard-limited to 32K. Why not 64k? Because the bootloader needs some memory in the same segment that it controls. Furthermore, since there were some residual uses of the 0x9000 segment (now removed, but not all bootloaders could be easily fixed), we were limited to about 40K for everything. Unfortunately we already have the problem that some bootloaders (notably LOADLIN and mknbi) hardcoded an arbitrary limit which was even smaller than that (about 16K, which we're already pushing up against.) Ok, that's a different argument than before. Ok. Although it's only a few bytes. I would lobby for any message at least contain the suggestion to try edd=off. That could save users a lot of time. The important thing is that there is a message before and after. The rest can be dealt with by Google on in documentation. That's what the patch currently in x86setup.git does. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Sat, 2007-12-22 at 01:28 +0100, Andi Kleen wrote: > Ingo Molnar <[EMAIL PROTECTED]> writes: > > > Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop > > relies on it, people use it every day to monitor memory consumption. > > It's definitely not a stable ABI. slabtop tends to exit without any > error message on any slabinfo version number increase and I've seen > that happen several times in not so old kernels. > > Requiring just another slabtop update isn't really a big deal. Might as well mention that SLOB also doesn't provide this functionality, nor would it make any sense for it to try (because there are no slab-like objects to report about). -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] PCI: use dev_printk in x86 quirk messages
* Greg KH <[EMAIL PROTECTED]> wrote: > How about you drop this one patch, and I'll keep it, as it goes along > with the other 2 patches in his series, and I'll make sure to check if > I have future pci quirk patches that affect the x86/ directory. > > Sound reasonable? sure enough - dropped. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/19] move _set_gate and its users to a common location
* Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote:
> This patch moves _set_gate and its users to desc.h. We can now use
> common code for x86_64 and i386.
a few days ago i started seeing weird crashes on 64-bit x86 in the
random-kernel-bootup tests. Nothing truly reproducable to be bisectable,
but quality of x86.git went down drastically. Double faults, triple
faults, crashes all around the place, with every few dozen kernel
bootups.
Today i found a config and a workload that triggered the crashes a bit
more reliably. I still needed a 6 hours bisection marathon to pinpoint
the patch - the one in this thread. A review of it with H. Peter Anvin
pinpointed the breakage:
> +static inline void set_system_gate(unsigned int n, void *addr)
> +{
> + BUG_ON((unsigned)n > 0xFF);
> + _set_gate(n, GATE_TRAP, addr, 0x3, 0, __KERNEL_CS);
> +}
> -static inline void set_system_gate(int nr, void *func)
> -{
> - BUG_ON((unsigned)nr > 0xFF);
> - _set_gate(nr, GATE_INTERRUPT, (unsigned long) func, 3, 0);
> -}
you changed the type of system gates on 64-bit from GATE_INTERRUPT to
GATE_TRAP. The effect of this is that these gates enter with interrupts
enabled - instead of interrupts disabled. This, amongst others, affects
the following key gate:
set_system_gate(IA32_SYSCALL_VECTOR, ia32_syscall);
which relies on disabled interrupts to fix up its stack. If an interrupt
comes in the wrong moment then we get a kernel stack corruption that is
not survivable.
the reason for this bug was that you tried to do too many changes in a
single patch. You did a cleanup, you did unification and you moved code
around. It was totally non-obvious what you did and the resulting patch
was not reviewable at all - even after the bisection poinpointed the
patch, it took us almost 30 minutes to figure out where the bug was. If
this unstructured, careless mess of patches continues then we are not
going to be able to accept any more 64-bit paravirt patches into
x86.git.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] eCryptfs: Change the type of cipher_code from u16 to u8
eCryptfs: Change the type of cipher_code from u16 to u8.
Only the lower byte of cipher_code is ever used, so it makes sense
for its type to be u8.
Signed-off-by: Trevor Highland <[EMAIL PROTECTED]>
---
fs/ecryptfs/crypto.c |8
fs/ecryptfs/ecryptfs_kernel.h |4 ++--
fs/ecryptfs/keystore.c|8
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 949fe44..5804400 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -1129,7 +1129,7 @@ write_ecryptfs_flags(char *page_virt, struct
ecryptfs_crypt_stat *crypt_stat,
struct ecryptfs_cipher_code_str_map_elem {
char cipher_str[16];
- u16 cipher_code;
+ u8 cipher_code;
};
/* Add support for additional ciphers by adding elements here. The
@@ -1153,10 +1153,10 @@ ecryptfs_cipher_code_str_map[] = {
*
* Returns zero on no match, or the cipher code on match
*/
-u16 ecryptfs_code_for_cipher_string(struct ecryptfs_crypt_stat *crypt_stat)
+u8 ecryptfs_code_for_cipher_string(struct ecryptfs_crypt_stat *crypt_stat)
{
int i;
- u16 code = 0;
+ u8 code = 0;
struct ecryptfs_cipher_code_str_map_elem *map =
ecryptfs_cipher_code_str_map;
@@ -1188,7 +1188,7 @@ u16 ecryptfs_code_for_cipher_string(struct
ecryptfs_crypt_stat *crypt_stat)
*
* Returns zero on success
*/
-int ecryptfs_cipher_code_to_string(char *str, u16 cipher_code)
+int ecryptfs_cipher_code_to_string(char *str, u8 cipher_code)
{
int rc = 0;
int i;
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index 114cb86..a991b4e 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -562,8 +562,8 @@ int ecryptfs_read_and_validate_header_region(char *data,
struct inode *ecryptfs_inode);
int ecryptfs_read_and_validate_xattr_region(char *page_virt,
struct dentry *ecryptfs_dentry);
-u16 ecryptfs_code_for_cipher_string(struct ecryptfs_crypt_stat *crypt_stat);
-int ecryptfs_cipher_code_to_string(char *str, u16 cipher_code);
+u8 ecryptfs_code_for_cipher_string(struct ecryptfs_crypt_stat *crypt_stat);
+int ecryptfs_cipher_code_to_string(char *str, u8 cipher_code);
void ecryptfs_set_default_sizes(struct ecryptfs_crypt_stat *crypt_stat);
int ecryptfs_generate_key_packet_set(char *dest_base,
struct ecryptfs_crypt_stat *crypt_stat,
diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
index 263fed8..0fe7c13 100644
--- a/fs/ecryptfs/keystore.c
+++ b/fs/ecryptfs/keystore.c
@@ -189,7 +189,7 @@ out:
}
static int
-parse_tag_65_packet(struct ecryptfs_session_key *session_key, u16 *cipher_code,
+parse_tag_65_packet(struct ecryptfs_session_key *session_key, u8 *cipher_code,
struct ecryptfs_message *msg)
{
size_t i = 0;
@@ -275,7 +275,7 @@ out:
static int
-write_tag_66_packet(char *signature, size_t cipher_code,
+write_tag_66_packet(char *signature, u8 cipher_code,
struct ecryptfs_crypt_stat *crypt_stat, char **packet,
size_t *packet_len)
{
@@ -428,7 +428,7 @@ static int
decrypt_pki_encrypted_session_key(struct ecryptfs_auth_tok *auth_tok,
struct ecryptfs_crypt_stat *crypt_stat)
{
- u16 cipher_code = 0;
+ u8 cipher_code = 0;
struct ecryptfs_msg_ctx *msg_ctx;
struct ecryptfs_message *msg = NULL;
char *auth_tok_sig;
@@ -1537,7 +1537,7 @@ write_tag_3_packet(char *dest, size_t *remaining_bytes,
struct scatterlist dst_sg;
struct scatterlist src_sg;
struct mutex *tfm_mutex = NULL;
- size_t cipher_code;
+ u8 cipher_code;
size_t packet_size_length;
size_t max_packet_size;
struct ecryptfs_mount_crypt_stat *mount_crypt_stat =
--
1.5.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] eCryptfs: Load each file decryption key only once
eCryptfs: Load each file decryption key only once
There is no need to keep re-setting the same key for any given
eCryptfs inode. This patch optimizes the use of the crypto API and
helps performance a bit.
Signed-off-by: Trevor Highland <[EMAIL PROTECTED]>
---
fs/ecryptfs/crypto.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 70f7aab..949fe44 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -353,7 +353,6 @@ static int encrypt_scatterlist(struct ecryptfs_crypt_stat
*crypt_stat,
ecryptfs_dump_hex(crypt_stat->key,
crypt_stat->key_size);
}
- /* Consider doing this once, when the file is opened */
mutex_lock(_stat->cs_tfm_mutex);
if (!(crypt_stat->flags & ECRYPTFS_KEY_SET)) {
rc = crypto_blkcipher_setkey(crypt_stat->tfm, crypt_stat->key,
@@ -687,10 +686,12 @@ static int decrypt_scatterlist(struct ecryptfs_crypt_stat
*crypt_stat,
};
int rc = 0;
- /* Consider doing this once, when the file is opened */
mutex_lock(_stat->cs_tfm_mutex);
- rc = crypto_blkcipher_setkey(crypt_stat->tfm, crypt_stat->key,
-crypt_stat->key_size);
+ if (!(crypt_stat->flags & ECRYPTFS_KEY_SET)) {
+ rc = crypto_blkcipher_setkey(crypt_stat->tfm, crypt_stat->key,
+crypt_stat->key_size);
+ crypt_stat->flags |= ECRYPTFS_KEY_SET;
+ }
if (rc) {
ecryptfs_printk(KERN_ERR, "Error setting key; rc = [%d]\n",
rc);
--
1.5.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] be more verbose when probing EDD
> Those don't live in an area of memory which is hard-limited to 32K. Why not 64k? Ok, that's a different argument than before. Ok. Although it's only a few bytes. I would lobby for any message at least contain the suggestion to try edd=off. That could save users a lot of time. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: compat_sys_times() bogus until jiffies >= 0.
> And to handle potentially ambiguous cases we, for a long time, have > the force_successful_syscall_return() arch hook. Ah I see what you mean now. Thanks for the clarification. Ok that could be in theory made to work yes. The migration would probably be ugly though (how would glibc figure out if the kernel does that or not?) -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] be more verbose when probing EDD
Andi Kleen wrote:
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
[EMAIL PROTECTED] wrote:
/* Query EDD information */
#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
- query_edd();
+printf("Probing EDD (query Bios for boot-device information)\n");
+printf("If boot hangs here, you may have a buggy Bios. Try edd=skipmbr or
edd=off");
+query_edd();
+printf("\rOK
\n");
#endif
This is awfully verbose.
But useful. On the other hand we have lots of IMNSHO
quite useless printks in early bootup that could be removed
to make up for that
(e.g. candidates would be the
"CPU: After/before generic identify"
or
Entering add_active_range)
printks and you can easily make up for the added verbosity.
Those don't live in an area of memory which is hard-limited to 32K.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: compat_sys_times() bogus until jiffies >= 0.
> I'm suggesting that you set the condition codes based upon whether > there is an error or not. And the only way the syscall code could find out if there is an error is by checking err < 0 && err >= -4096 like glibc (except for the compat syscall on 64bit kernel case) Or rewrite all code that returns errors to system calls to pass a separate flag too. > That is the critical thing x86 doesn't do > that all the other platforms do. It doesn't do it because it's useless without a kernel rewrite. I frankly doubt it really works on Sparc :-) Maybe it could work there on a hypothetical rewritten kernel, but not today. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: compat_sys_times() bogus until jiffies >= 0.
From: David Miller <[EMAIL PROTECTED]> Date: Fri, 21 Dec 2007 17:41:24 -0800 (PST) > I'm suggesting that you set the condition codes based upon whether > there is an error or not. That is the critical thing x86 doesn't do > that all the other platforms do. And if you still don't get it, I'm saying that x86, in the syscall trap return path, should set the conditon codes based upon whether the system call is really signalling an error or not. And to handle potentially ambiguous cases we, for a long time, have the force_successful_syscall_return() arch hook. System call implementations use this when the return values they give could be mis-construed as error values. And if you'll notice x86 makes no attempt to implement that hook, because it currently can't. That's what needs to be fixed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: compat_sys_times() bogus until jiffies >= 0.
From: Andi Kleen <[EMAIL PROTECTED]> Date: Sat, 22 Dec 2007 01:42:02 +0100 > David Miller <[EMAIL PROTECTED]> writes: > > > Only on x86 platforms. Sparc, IA64, MIPS, powerpc, etc. all get this > > case right. > > Do they for 32bit kernels or for 64bit userland? Both. This is not a compat issue. > > Yes it's another unfortunate side effect of how error status is > > indicated for x86 system calls. > > Maybe I'm dense, but doesn't all the kernel code pass it the > same way as the x86 syscall code? For your proposal you > would need a separate error bit coming out of the sys_* to > handle this case. Basically rewrite all code that ever returns > errors in the kernel. Or do I miss something? I'm suggesting that you set the condition codes based upon whether there is an error or not. That is the critical thing x86 doesn't do that all the other platforms do. x86 relies on interpretation of purely the integer returned from the system call to userspace, and that means a certain chunk of the return value space can never represent valid values. If you use the condition codes to signal "the return value is an error" you don't have these problems. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] readahead: save mmap read-around states in file_ra_state
Change mmap read-around to share the same code style and data structure
with readahead code.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
mm/filemap.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
--- linux-2.6.24-rc5-mm1.orig/mm/filemap.c
+++ linux-2.6.24-rc5-mm1/mm/filemap.c
@@ -1334,13 +1334,15 @@ static void do_sync_mmap_readahead(struc
if (ra->mmap_miss > MMAP_LOTSAMISS)
return;
+ /*
+* mmap read-around
+*/
ra_pages = max_sane_readahead(ra->ra_pages);
if (ra_pages) {
- pgoff_t start = 0;
-
- if (offset > ra_pages / 2)
- start = offset - ra_pages / 2;
- do_page_cache_readahead(mapping, file, start, ra_pages);
+ ra->start = max_t(long, 0, offset - ra_pages / 2);
+ ra->size = ra_pages;
+ ra->async_size = 0;
+ ra_submit(ra, mapping, file);
}
}
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] readahead: clean up and simplify the code for filemap page fault readahead
From: Linus Torvalds <[EMAIL PROTECTED]>
This shouldn't really change behavior all that much, but the single
rather complex function with read-ahead inside a loop etc is broken up
into more manageable pieces.
The behaviour is also less subtle, with the read-ahead being done up-front
rather than inside some subtle loop and thus avoiding the now unnecessary
extra state variables (ie "did_readaround" is gone).
Cc: Nick Piggin <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Cc: Fengguang Wu <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
Ok, so this is something I did in Mexico when I wasn't scuba-diving, and
was "watching" the kids at the pool. It was brought on by looking at git
mmap file behaviour under cold-cache behaviour: git does ok, but my laptop
disk is really slow, and I tried to verify that the kernel did a
reasonable job of read-ahead when taking page faults.
I think it did, but quite frankly, the filemap_fault() code was totally
unreadable. So this separates out the read-ahead cases, and adds more
comments, and also changes it so that we do asynchronous read-ahead
*before* we actually wait for the page we are waiting for to become
unlocked.
Not that it seems to make any real difference on my laptop, but I really
hated how it was doing a
page = get_lock_page(..)
and then doing read-ahead after that: which just guarantees that we have
to wait for any out-standing IO on "page" to complete before we can even
submit any new read-ahead! That just seems totally broken!
So it replaces the "get_lock_page()" at the top with a broken-out page
cache lookup, which allows us to look at the page state flags and make
appropriate decisions on what we should do without waiting for the locked
bit to clear.
It does add many more lines than it removes:
mm/filemap.c | 192
+++---
1 files changed, 130 insertions(+), 62 deletions(-)
but that's largely due to (a) the new function headers etc due to the
split-up and (b) new or extended comments especially about the helper
functions. The code, in many ways, is actually simpler, apart from the
fairly trivial expansion of the equivalent of "get_lock_page()" into the
function.
Comments? I tried to avoid changing the read-ahead logic itself, although
the old code did some strange things like doing *both* async readahead and
then looking up the page and doing sync readahead (which I think was just
due to the code being so damn messily organized, not on purpose).
Linus
---
mm/filemap.c | 156 +++--
1 file changed, 89 insertions(+), 67 deletions(-)
--- linux-2.6.24-rc5-mm1.orig/mm/filemap.c
+++ linux-2.6.24-rc5-mm1/mm/filemap.c
@@ -1302,6 +1302,68 @@ static int fastcall page_cache_read(stru
#define MMAP_LOTSAMISS (100)
+/*
+ * Synchronous readahead happens when we don't even find
+ * a page in the page cache at all.
+ */
+static void do_sync_mmap_readahead(struct vm_area_struct *vma,
+ struct file_ra_state *ra,
+ struct file *file,
+ pgoff_t offset)
+{
+ unsigned long ra_pages;
+ struct address_space *mapping = file->f_mapping;
+
+ /* If we don't want any read-ahead, don't bother */
+ if (VM_RandomReadHint(vma))
+ return;
+
+ if (VM_SequentialReadHint(vma)) {
+ page_cache_sync_readahead(mapping, ra, file, offset, 1);
+ return;
+ }
+
+ if (ra->mmap_miss < INT_MAX)
+ ra->mmap_miss++;
+
+ /*
+* Do we miss much more than hit in this file? If so,
+* stop bothering with read-ahead. It will only hurt.
+*/
+ if (ra->mmap_miss > MMAP_LOTSAMISS)
+ return;
+
+ ra_pages = max_sane_readahead(ra->ra_pages);
+ if (ra_pages) {
+ pgoff_t start = 0;
+
+ if (offset > ra_pages / 2)
+ start = offset - ra_pages / 2;
+ do_page_cache_readahead(mapping, file, start, ra_pages);
+ }
+}
+
+/*
+ * Asynchronous readahead happens when we find the page and PG_readahead,
+ * so we want to possibly extend the readahead further..
+ */
+static void do_async_mmap_readahead(struct vm_area_struct *vma,
+ struct file_ra_state *ra,
+ struct file *file,
+ struct page *page,
+ pgoff_t offset)
+{
+ struct address_space *mapping = file->f_mapping;
+
+ /* If we don't want any read-ahead, don't bother */
+ if (VM_RandomReadHint(vma))
+ return;
+ if (ra->mmap_miss > 0)
+ ra->mmap_miss--;
+ if (PageReadahead(page))
+ page_cache_async_readahead(mapping, ra, file, page, offset,
[PATCH 3/9] readahead: auto detection of sequential mmap reads
Auto-detect sequential mmap reads and do sync/async readahead for them.
The sequential mmap readahead will be triggered when
- sync readahead: it's a major fault and (prev_offset==offset-1);
- async readahead: minor fault on PG_readahead page with valid readahead state.
It's a bit conservative to require valid readahead state for async readahead,
which means we don't do readahead for interleaved reads for now, but let's make
it safe for this initial try.
==
The benefits of doing readahead instead of read-around:
- less I/O wait thanks to async readahead
- double real I/O size and no more cache hits
Some numbers on 100,000 sequential mmap reads:
user systemcputotal
(1-1) plain -mm, 128KB readaround: 3.224 2.554 48.40% 11.838
(1-2) plain -mm, 256KB readaround: 3.170 2.392 46.20% 11.976
(2) patched -mm, 128KB readahead: 3.117 2.448 47.33% 11.607
The patched (2) has smallest total time. It has no cache hit overheads
and less I/O block time(thanks to async readahead). Here the I/O size
makes no much difference, since there's only one single stream.
Note that (1-1)'s real I/O size is 64KB and (1-2)'s real I/O size is
128KB, since the half of the read-around pages will be cache hits.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
---
mm/filemap.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-2.6.24-rc5-mm1.orig/mm/filemap.c
+++ linux-2.6.24-rc5-mm1/mm/filemap.c
@@ -1318,7 +1318,8 @@ static void do_sync_mmap_readahead(struc
if (VM_RandomReadHint(vma))
return;
- if (VM_SequentialReadHint(vma)) {
+ if (VM_SequentialReadHint(vma) ||
+ offset - 1 == (ra->prev_pos >> PAGE_CACHE_SHIFT)) {
page_cache_sync_readahead(mapping, ra, file, offset, 1);
return;
}
@@ -1360,7 +1361,8 @@ static void do_async_mmap_readahead(stru
return;
if (ra->mmap_miss > 0)
ra->mmap_miss--;
- if (PageReadahead(page))
+ if (PageReadahead(page) &&
+ offset == ra->start + ra->size - ra->async_size)
page_cache_async_readahead(mapping, ra, file, page, offset, 1);
}
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/9] mmap read-around and readahead take 2
Andrew, Here are the mmap read-around related patches initiated by Linus. They are for linux-2.6.24-rc5-mm1. They're mainly about code cleanups. The only major new feature - auto detection and early readahead for mmap sequential reads - shows about 2% speedup on single stream case, and should perform much better in multiple streams case. This take: simplified patch 2, from mm/filemap.c | 192 +++--- 1 files changed, 130 insertions(+), 62 deletions(-) to mm/filemap.c | 156 +++-- 1 file changed, 89 insertions(+), 67 deletions(-) [PATCH 1/9] readahead: simplify readahead call scheme [PATCH 2/9] readahead: clean up and simplify the code for filemap page fault readahead [PATCH 3/9] readahead: auto detection of sequential mmap reads [PATCH 4/9] readahead: quick startup on sequential mmap readahead [PATCH 5/9] readahead: make ra_submit() non-static [PATCH 6/9] readahead: save mmap read-around states in file_ra_state [PATCH 7/9] readahead: remove unused do_page_cache_readahead() [PATCH 8/9] readahead: move max_sane_readahead() calls into force_page_cache_readahead() [PATCH 9/9] readahead: call max_sane_readahead() in ondemand_readahead() Thank you, Fengguang -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] readahead: simplify readahead call scheme
It is insane and error-prone to insist on the call sites to check for async readahead after doing any sync one. I.e. whenever someone do a sync readahead: if (!page) page_cache_sync_readahead(...); He must try async readahead, too: page = find_get_page(...); if (PageReadahead(page)) page_cache_async_readahead(...); The tricky point is that PG_readahead could be set by a sync readahead for the _current_ newly faulted in page, and the readahead code simply expects one more callback to handle it. If the caller fails to do so, it will miss the PG_readahead bits and never able to start an async readahead. Avoid it by piggy-backing the async part _inside_ the readahead code. Now if an async readahead should be started immediately after a sync one, the readahead logic itself will do it. So the following code becomes valid: if (!page) page_cache_sync_readahead(...); else if (PageReadahead(page)) page_cache_async_readahead(...); Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]> --- mm/readahead.c |8 1 file changed, 8 insertions(+) --- linux-2.6.24-rc5-mm1.orig/mm/readahead.c +++ linux-2.6.24-rc5-mm1/mm/readahead.c @@ -402,6 +402,14 @@ ondemand_readahead(struct address_space ra->async_size = ra->size > req_size ? ra->size - req_size : ra->size; readit: + /* +* An async readahead should be triggered immediately. +* Instead of demanding all call sites to check for async readahead +* immediate after a sync one, start the async part now and here. +*/ + if (!hit_readahead_marker && ra->size == ra->async_size) + ra->size *= 2; + return ra_submit(ra, mapping, filp); } -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] readahead: quick startup on sequential mmap readahead
When the user explicitly sets MADV_SEQUENTIAL, we should really avoid the slow
readahead size ramp-up phase and start full-size readahead immediately.
This patch won't change behavior for the auto-detected sequential mmap reads.
Its previous read-around size is ra_pages/2, so it will be doubled to the full
readahead size anyway.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
mm/filemap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.24-rc5-mm1.orig/mm/filemap.c
+++ linux-2.6.24-rc5-mm1/mm/filemap.c
@@ -1320,7 +1320,7 @@ static void do_sync_mmap_readahead(struc
if (VM_SequentialReadHint(vma) ||
offset - 1 == (ra->prev_pos >> PAGE_CACHE_SHIFT)) {
- page_cache_sync_readahead(mapping, ra, file, offset, 1);
+ page_cache_sync_readahead(mapping, ra, file, offset,
ra->ra_pages);
return;
}
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] readahead: move max_sane_readahead() calls into force_page_cache_readahead()
Simplify code by moving max_sane_readahead() calls into
force_page_cache_readahead().
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
mm/fadvise.c |2 +-
mm/filemap.c |3 +--
mm/madvise.c |3 +--
mm/readahead.c |1 +
4 files changed, 4 insertions(+), 5 deletions(-)
--- linux-2.6.24-rc5-mm1.orig/mm/fadvise.c
+++ linux-2.6.24-rc5-mm1/mm/fadvise.c
@@ -89,7 +89,7 @@ asmlinkage long sys_fadvise64_64(int fd,
ret = force_page_cache_readahead(mapping, file,
start_index,
- max_sane_readahead(nrpages));
+ nrpages);
if (ret > 0)
ret = 0;
break;
--- linux-2.6.24-rc5-mm1.orig/mm/filemap.c
+++ linux-2.6.24-rc5-mm1/mm/filemap.c
@@ -1242,8 +1242,7 @@ do_readahead(struct address_space *mappi
if (!mapping || !mapping->a_ops || !mapping->a_ops->readpage)
return -EINVAL;
- force_page_cache_readahead(mapping, filp, index,
- max_sane_readahead(nr));
+ force_page_cache_readahead(mapping, filp, index, nr);
return 0;
}
--- linux-2.6.24-rc5-mm1.orig/mm/madvise.c
+++ linux-2.6.24-rc5-mm1/mm/madvise.c
@@ -123,8 +123,7 @@ static long madvise_willneed(struct vm_a
end = vma->vm_end;
end = ((end - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
- force_page_cache_readahead(file->f_mapping,
- file, start, max_sane_readahead(end - start));
+ force_page_cache_readahead(file->f_mapping, file, start, end - start);
return 0;
}
--- linux-2.6.24-rc5-mm1.orig/mm/readahead.c
+++ linux-2.6.24-rc5-mm1/mm/readahead.c
@@ -187,6 +187,7 @@ int force_page_cache_readahead(struct ad
if (unlikely(!mapping->a_ops->readpage && !mapping->a_ops->readpages))
return -EINVAL;
+ nr_to_read = max_sane_readahead(nr_to_read);
while (nr_to_read) {
int err;
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] readahead: remove unused do_page_cache_readahead()
Remove do_page_cache_readahead().
Its last user, mmap read-around, has been changed to call ra_submit().
Also, the no-readahead-if-congested logic is not appropriate here.
Raw 1-page reads can only makes things painfully slower, and
users are pretty sensitive about the slow loading of executables.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
include/linux/mm.h |2 --
mm/readahead.c | 16
2 files changed, 18 deletions(-)
--- linux-2.6.24-rc5-mm1.orig/include/linux/mm.h
+++ linux-2.6.24-rc5-mm1/include/linux/mm.h
@@ -1084,8 +1084,6 @@ int write_one_page(struct page *page, in
#define VM_MAX_READAHEAD 128 /* kbytes */
#define VM_MIN_READAHEAD 16 /* kbytes (includes current page) */
-int do_page_cache_readahead(struct address_space *mapping, struct file *filp,
- pgoff_t offset, unsigned long nr_to_read);
int force_page_cache_readahead(struct address_space *mapping, struct file
*filp,
pgoff_t offset, unsigned long nr_to_read);
--- linux-2.6.24-rc5-mm1.orig/mm/readahead.c
+++ linux-2.6.24-rc5-mm1/mm/readahead.c
@@ -208,22 +208,6 @@ int force_page_cache_readahead(struct ad
}
/*
- * This version skips the IO if the queue is read-congested, and will tell the
- * block layer to abandon the readahead if request allocation would block.
- *
- * force_page_cache_readahead() will ignore queue congestion and will block on
- * request queues.
- */
-int do_page_cache_readahead(struct address_space *mapping, struct file *filp,
- pgoff_t offset, unsigned long nr_to_read)
-{
- if (bdi_read_congested(mapping->backing_dev_info))
- return -1;
-
- return __do_page_cache_readahead(mapping, filp, offset, nr_to_read, 0);
-}
-
-/*
* Given a desired number of PAGE_CACHE_SIZE readahead pages, return a
* sensible upper limit.
*/
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] readahead: call max_sane_readahead() in ondemand_readahead()
Apply the max_sane_readahead() limit in ondemand_readahead().
Just in case someone aggressively set a huge readahead size.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
mm/readahead.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.24-rc5-mm1.orig/mm/readahead.c
+++ linux-2.6.24-rc5-mm1/mm/readahead.c
@@ -324,9 +324,9 @@ ondemand_readahead(struct address_space
bool hit_readahead_marker, pgoff_t offset,
unsigned long req_size)
{
- int max = ra->ra_pages; /* max readahead pages */
pgoff_t prev_offset;
- int sequential;
+ int sequential;
+ int max = max_sane_readahead(ra->ra_pages); /* max readahead pages */
/*
* It's the expected callback offset, assume sequential access.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] readahead: make ra_submit() non-static
Make ra_submit() non-static and callable from other files.
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
---
include/linux/mm.h |3 +++
mm/readahead.c |2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
--- linux-2.6.24-rc5-mm1.orig/include/linux/mm.h
+++ linux-2.6.24-rc5-mm1/include/linux/mm.h
@@ -1103,6 +1103,9 @@ void page_cache_async_readahead(struct a
unsigned long size);
unsigned long max_sane_readahead(unsigned long nr);
+unsigned long ra_submit(struct file_ra_state *ra,
+ struct address_space *mapping,
+ struct file *filp);
/* Do stack extension */
extern int expand_stack(struct vm_area_struct *vma, unsigned long address);
--- linux-2.6.24-rc5-mm1.orig/mm/readahead.c
+++ linux-2.6.24-rc5-mm1/mm/readahead.c
@@ -242,7 +242,7 @@ subsys_initcall(readahead_init);
/*
* Submit IO for the read-ahead request in file_ra_state.
*/
-static unsigned long ra_submit(struct file_ra_state *ra,
+unsigned long ra_submit(struct file_ra_state *ra,
struct address_space *mapping, struct file *filp)
{
int actual;
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RFC] be more verbose when probing EDD
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> /* Query EDD information */
>> #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
>> - query_edd();
>> +printf("Probing EDD (query Bios for boot-device information)\n");
>> +printf("If boot hangs here, you may have a buggy Bios. Try
>> edd=skipmbr or edd=off");
>> +query_edd();
>> +printf("\rOK
>>\n");
>> #endif
>
> This is awfully verbose.
But useful. On the other hand we have lots of IMNSHO
quite useless printks in early bootup that could be removed
to make up for that
(e.g. candidates would be the
"CPU: After/before generic identify"
or
Entering add_active_range)
printks and you can easily make up for the added verbosity.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/urandom uses uninit bytes, leaks user data
On Fri, Dec 21, 2007 at 11:10:36AM -0500, Andrew Lutomirski wrote: > > > Step 1: Boot a system without a usable entropy source. > > > Step 2: add some (predictable) "entropy" from userspace which isn't a > > > multiple of 4, so up to three extra bytes get added. > > > Step 3: Read a few bytes of /dev/random and send them over the network. > > > > Only root can do 1 and 2, at which point, it's already game over. > > Again, no. Root could do this accidentally. Step 1 happens all the > time (see the comments on non-unique UUIDs). Actually, it doesn't happen *all* the time. That was a situation of an rpm post-install script trying to use a random UUID generation facility from a kick-start install where there was no keyboard activity and apparently no other entropy added. (Note that in such an environment, generation of host ssh keys at install time without any entropy is an even bigger problem, and that *is* something that people should be thinking about.) > Step 2 just requires a > program to put data which it things is OK to go into the pool next to > data that shouldn't be there in memory. Um, no, that's incorrect. Simply putting data which is OK to put into the pool next to data that shouldn't isn't enough. First of all, the issue is using unitialized kernel stack garbage. Read that again, slowly --- kernel stack. How you arrange your data in user memory doesn't matter. Secondly, as I've said earlier, I'm not aware of any program that actually tries to write into the entropy pool on most modern Linux systems other than dd in /etc/init.d/random which initializes the random pool from pre-seeded entropy on disk. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] async_tx: kill tx_set_src and tx_set_dest methods
The tx_set_src and tx_set_dest methods were originally implemented to allow
an array of addresses to be passed down from async_xor to the dmaengine
driver while minimizing stack overhead. Removing these methods allows
drivers to have all transaction parameters available at 'prep' time, saves
two function pointers in struct dma_async_tx_descriptor, and reduces the
number of indirect branches..
A consequence of moving this data to the 'prep' routine is that
multi-source routines like async_xor need temporary storage to convert an
array of linear addresses into an array of dma addresses. In order to keep
the same stack footprint of the previous implementation the input array is
reused as storage for the dma addresses. This requires that
sizeof(dma_addr_t) be less than or equal to sizeof(void *). As a
consequence CONFIG_DMADEVICES now depends on !CONFIG_HIGHMEM64G. It also
requires that drivers be able to make descriptor resources available when
the 'prep' routine is polled.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
crypto/async_tx/async_memcpy.c | 27 -
crypto/async_tx/async_memset.c | 20 +++---
crypto/async_tx/async_xor.c| 94 +++---
drivers/dma/Kconfig|1
drivers/dma/dmaengine.c| 49 +---
drivers/dma/ioat_dma.c | 39 +
drivers/dma/iop-adma.c | 124 ++--
include/linux/dmaengine.h | 20 +++---
8 files changed, 178 insertions(+), 196 deletions(-)
diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
index e8c8956..faca0bc 100644
--- a/crypto/async_tx/async_memcpy.c
+++ b/crypto/async_tx/async_memcpy.c
@@ -48,26 +48,25 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
{
struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_MEMCPY);
struct dma_device *device = chan ? chan->device : NULL;
- int int_en = cb_fn ? 1 : 0;
- struct dma_async_tx_descriptor *tx = device ?
- device->device_prep_dma_memcpy(chan, len,
- int_en) : NULL;
+ struct dma_async_tx_descriptor *tx = NULL;
- if (tx) { /* run the memcpy asynchronously */
- dma_addr_t addr;
+ if (device) {
+ dma_addr_t dma_dest, dma_src;
- pr_debug("%s: (async) len: %zu\n", __FUNCTION__, len);
+ dma_dest = dma_map_page(device->dev, dest, dest_offset, len,
+ DMA_FROM_DEVICE);
- addr = dma_map_page(device->dev, dest, dest_offset, len,
- DMA_FROM_DEVICE);
- tx->tx_set_dest(addr, tx, 0);
+ dma_src = dma_map_page(device->dev, src, src_offset, len,
+ DMA_TO_DEVICE);
- addr = dma_map_page(device->dev, src, src_offset, len,
- DMA_TO_DEVICE);
- tx->tx_set_src(addr, tx, 0);
+ tx = device->device_prep_dma_memcpy(chan, dma_dest, dma_src,
+ len, cb_fn != NULL);
+ }
+ if (tx) {
+ pr_debug("%s: (async) len: %zu\n", __FUNCTION__, len);
async_tx_submit(chan, tx, flags, depend_tx, cb_fn, cb_param);
- } else { /* run the memcpy synchronously */
+ } else {
void *dest_buf, *src_buf;
pr_debug("%s: (sync) len: %zu\n", __FUNCTION__, len);
diff --git a/crypto/async_tx/async_memset.c b/crypto/async_tx/async_memset.c
index 7609728..0c94851 100644
--- a/crypto/async_tx/async_memset.c
+++ b/crypto/async_tx/async_memset.c
@@ -48,20 +48,20 @@ async_memset(struct page *dest, int val, unsigned int
offset,
{
struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_MEMSET);
struct dma_device *device = chan ? chan->device : NULL;
- int int_en = cb_fn ? 1 : 0;
- struct dma_async_tx_descriptor *tx = device ?
- device->device_prep_dma_memset(chan, val, len,
- int_en) : NULL;
+ struct dma_async_tx_descriptor *tx = NULL;
- if (tx) { /* run the memset asynchronously */
- dma_addr_t dma_addr;
+ if (device) {
+ dma_addr_t dma_dest;
- pr_debug("%s: (async) len: %zu\n", __FUNCTION__, len);
-
- dma_addr = dma_map_page(device->dev, dest, offset, len,
+ dma_dest = dma_map_page(device->dev, dest, offset, len,
DMA_FROM_DEVICE);
- tx->tx_set_dest(dma_addr, tx, 0);
+ tx = device->device_prep_dma_memset(chan, dma_dest, val, len,
+ cb_fn != NULL);
+ }
+
+ if (tx) {
+ pr_debug("%s: (async) len: %zu\n", __FUNCTION__, len);
async_tx_submit(chan, tx, flags, depend_tx, cb_fn,
[PATCH 0/4] towards an async_tx update for 2.6.25
Prompted by Yuri's RAID6 acceleration implementation [1], and Haavard's DMA-slave interface [2], this series cleans up the async_tx api and prepares it for these new features. The most invasive change is the removal of the tx_set_src and tx_set_dest methods in patch 2/4, drivers now receive all necessary operation information at 'prep' time. Still on the to do list: * Pull the mpc85xx driver from -mm and integrate these api changes * Apply Haavard's dma-test-client [3]. Look into extending it for other operations and async_tx channel switching testing * Teach async_tx about drivers that do not support channel switching This series is based on 2.6.24-rc6. Dan Williams (4): async_tx: kill ASYNC_TX_ASSUME_COHERENT async_tx: kill tx_set_src and tx_set_dest methods async_tx: replace 'int_en' with operation preparation flags async_tx: allow architecture specific async_tx_find_channel implementations crypto/async_tx/async_memcpy.c | 38 - crypto/async_tx/async_memset.c | 28 +++--- crypto/async_tx/async_tx.c |6 +- crypto/async_tx/async_xor.c| 120 + drivers/dma/Kconfig|1 + drivers/dma/dmaengine.c| 49 +++- drivers/dma/ioat_dma.c | 43 -- drivers/dma/iop-adma.c | 136 include/asm-arm/arch-iop13xx/adma.h| 18 +++-- include/asm-arm/hardware/iop3xx-adma.h | 30 --- include/linux/async_tx.h | 13 ++- include/linux/dmaengine.h | 29 --- 12 files changed, 253 insertions(+), 258 deletions(-) -- Dan [1] http://marc.info/?l=linux-raid=119676789912370=2 [2] http://marc.info/?l=linux-kernel=119582072930013=2 [3] http://marc.info/?l=linux-kernel=119583211214496=2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] async_tx: kill ASYNC_TX_ASSUME_COHERENT
Remove the unused ASYNC_TX_ASSUME_COHERENT flag. Async_tx is
meant to hide the difference between asynchronous hardware and synchronous
software operations, this flag requires clients to understand cache
coherency consequences of the async path.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
crypto/async_tx/async_memcpy.c | 15 +--
crypto/async_tx/async_memset.c |8 +++-
crypto/async_tx/async_xor.c| 22 ++
include/linux/async_tx.h |2 --
4 files changed, 14 insertions(+), 33 deletions(-)
diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
index 047e533..e8c8956 100644
--- a/crypto/async_tx/async_memcpy.c
+++ b/crypto/async_tx/async_memcpy.c
@@ -35,7 +35,7 @@
* @src: src page
* @offset: offset in pages to start transaction
* @len: length in bytes
- * @flags: ASYNC_TX_ASSUME_COHERENT, ASYNC_TX_ACK, ASYNC_TX_DEP_ACK,
+ * @flags: ASYNC_TX_ACK, ASYNC_TX_DEP_ACK,
* @depend_tx: memcpy depends on the result of this transaction
* @cb_fn: function to call when the memcpy completes
* @cb_param: parameter to pass to the callback routine
@@ -55,20 +55,15 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
if (tx) { /* run the memcpy asynchronously */
dma_addr_t addr;
- enum dma_data_direction dir;
pr_debug("%s: (async) len: %zu\n", __FUNCTION__, len);
- dir = (flags & ASYNC_TX_ASSUME_COHERENT) ?
- DMA_NONE : DMA_FROM_DEVICE;
-
- addr = dma_map_page(device->dev, dest, dest_offset, len, dir);
+ addr = dma_map_page(device->dev, dest, dest_offset, len,
+ DMA_FROM_DEVICE);
tx->tx_set_dest(addr, tx, 0);
- dir = (flags & ASYNC_TX_ASSUME_COHERENT) ?
- DMA_NONE : DMA_TO_DEVICE;
-
- addr = dma_map_page(device->dev, src, src_offset, len, dir);
+ addr = dma_map_page(device->dev, src, src_offset, len,
+ DMA_TO_DEVICE);
tx->tx_set_src(addr, tx, 0);
async_tx_submit(chan, tx, flags, depend_tx, cb_fn, cb_param);
diff --git a/crypto/async_tx/async_memset.c b/crypto/async_tx/async_memset.c
index 66ef635..7609728 100644
--- a/crypto/async_tx/async_memset.c
+++ b/crypto/async_tx/async_memset.c
@@ -35,7 +35,7 @@
* @val: fill value
* @offset: offset in pages to start transaction
* @len: length in bytes
- * @flags: ASYNC_TX_ASSUME_COHERENT, ASYNC_TX_ACK, ASYNC_TX_DEP_ACK
+ * @flags: ASYNC_TX_ACK, ASYNC_TX_DEP_ACK
* @depend_tx: memset depends on the result of this transaction
* @cb_fn: function to call when the memcpy completes
* @cb_param: parameter to pass to the callback routine
@@ -55,13 +55,11 @@ async_memset(struct page *dest, int val, unsigned int
offset,
if (tx) { /* run the memset asynchronously */
dma_addr_t dma_addr;
- enum dma_data_direction dir;
pr_debug("%s: (async) len: %zu\n", __FUNCTION__, len);
- dir = (flags & ASYNC_TX_ASSUME_COHERENT) ?
- DMA_NONE : DMA_FROM_DEVICE;
- dma_addr = dma_map_page(device->dev, dest, offset, len, dir);
+ dma_addr = dma_map_page(device->dev, dest, offset, len,
+ DMA_FROM_DEVICE);
tx->tx_set_dest(dma_addr, tx, 0);
async_tx_submit(chan, tx, flags, depend_tx, cb_fn, cb_param);
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index 2575f67..f332ddc 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -38,23 +38,17 @@ do_async_xor(struct dma_async_tx_descriptor *tx, struct
dma_device *device,
dma_async_tx_callback cb_fn, void *cb_param)
{
dma_addr_t dma_addr;
- enum dma_data_direction dir;
int i;
pr_debug("%s: len: %zu\n", __FUNCTION__, len);
- dir = (flags & ASYNC_TX_ASSUME_COHERENT) ?
- DMA_NONE : DMA_FROM_DEVICE;
-
- dma_addr = dma_map_page(device->dev, dest, offset, len, dir);
+ dma_addr = dma_map_page(device->dev, dest, offset, len,
+ DMA_FROM_DEVICE);
tx->tx_set_dest(dma_addr, tx, 0);
- dir = (flags & ASYNC_TX_ASSUME_COHERENT) ?
- DMA_NONE : DMA_TO_DEVICE;
-
for (i = 0; i < src_cnt; i++) {
dma_addr = dma_map_page(device->dev, src_list[i],
- offset, len, dir);
+ offset, len, DMA_TO_DEVICE);
tx->tx_set_src(dma_addr, tx, i);
}
@@ -102,7 +96,7 @@ do_sync_xor(struct page *dest, struct page **src_list,
unsigned int offset,
* @src_cnt: number of source pages
* @len: length in bytes
* @flags: ASYNC_TX_XOR_ZERO_DST, ASYNC_TX_XOR_DROP_DEST,
- * ASYNC_TX_ASSUME_COHERENT, ASYNC_TX_ACK,
[PATCH 4/4] async_tx: allow architecture specific async_tx_find_channel implementations
The source and destination addresses are included to allow channel
selection based on address alignment.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
crypto/async_tx/async_memcpy.c |3 ++-
crypto/async_tx/async_memset.c |3 ++-
crypto/async_tx/async_tx.c |6 +++---
crypto/async_tx/async_xor.c|8 ++--
include/linux/async_tx.h | 11 +--
5 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
index 25dcf33..0f62822 100644
--- a/crypto/async_tx/async_memcpy.c
+++ b/crypto/async_tx/async_memcpy.c
@@ -46,7 +46,8 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
struct dma_async_tx_descriptor *depend_tx,
dma_async_tx_callback cb_fn, void *cb_param)
{
- struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_MEMCPY);
+ struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_MEMCPY,
+ , 1, , 1, len);
struct dma_device *device = chan ? chan->device : NULL;
struct dma_async_tx_descriptor *tx = NULL;
diff --git a/crypto/async_tx/async_memset.c b/crypto/async_tx/async_memset.c
index 8e98ab0..09c0e83 100644
--- a/crypto/async_tx/async_memset.c
+++ b/crypto/async_tx/async_memset.c
@@ -46,7 +46,8 @@ async_memset(struct page *dest, int val, unsigned int offset,
struct dma_async_tx_descriptor *depend_tx,
dma_async_tx_callback cb_fn, void *cb_param)
{
- struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_MEMSET);
+ struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_MEMSET,
+ , 1, NULL, 0, len);
struct dma_device *device = chan ? chan->device : NULL;
struct dma_async_tx_descriptor *tx = NULL;
diff --git a/crypto/async_tx/async_tx.c b/crypto/async_tx/async_tx.c
index f39777f..5628821 100644
--- a/crypto/async_tx/async_tx.c
+++ b/crypto/async_tx/async_tx.c
@@ -361,13 +361,13 @@ static void __exit async_tx_exit(void)
}
/**
- * async_tx_find_channel - find a channel to carry out the operation or let
+ * __async_tx_find_channel - find a channel to carry out the operation or let
* the transaction execute synchronously
* @depend_tx: transaction dependency
* @tx_type: transaction type
*/
struct dma_chan *
-async_tx_find_channel(struct dma_async_tx_descriptor *depend_tx,
+__async_tx_find_channel(struct dma_async_tx_descriptor *depend_tx,
enum dma_transaction_type tx_type)
{
/* see if we can keep the chain on one channel */
@@ -383,7 +383,7 @@ async_tx_find_channel(struct dma_async_tx_descriptor
*depend_tx,
} else
return NULL;
}
-EXPORT_SYMBOL_GPL(async_tx_find_channel);
+EXPORT_SYMBOL_GPL(__async_tx_find_channel);
#else
static int __init async_tx_init(void)
{
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index 80f30bc..e6dfacc 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -125,7 +125,9 @@ async_xor(struct page *dest, struct page **src_list,
unsigned int offset,
struct dma_async_tx_descriptor *depend_tx,
dma_async_tx_callback cb_fn, void *cb_param)
{
- struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_XOR);
+ struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_XOR,
+ , 1, src_list,
+ src_cnt, len);
struct dma_device *device = chan ? chan->device : NULL;
struct dma_async_tx_descriptor *tx = NULL;
dma_async_tx_callback _cb_fn;
@@ -257,7 +259,9 @@ async_xor_zero_sum(struct page *dest, struct page
**src_list,
struct dma_async_tx_descriptor *depend_tx,
dma_async_tx_callback cb_fn, void *cb_param)
{
- struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_ZERO_SUM);
+ struct dma_chan *chan = async_tx_find_channel(depend_tx, DMA_ZERO_SUM,
+ , 1, src_list,
+ src_cnt, len);
struct dma_device *device = chan ? chan->device : NULL;
struct dma_async_tx_descriptor *tx = NULL;
diff --git a/include/linux/async_tx.h b/include/linux/async_tx.h
index 3d59d37..eb640f0 100644
--- a/include/linux/async_tx.h
+++ b/include/linux/async_tx.h
@@ -62,9 +62,15 @@ enum async_tx_flags {
void async_tx_issue_pending_all(void);
enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
void async_tx_run_dependencies(struct dma_async_tx_descriptor *tx);
+#ifdef CONFIG_ARCH_HAS_ASYNC_TX_FIND_CHANNEL
+#include
+#else
+#define async_tx_find_channel(dep, type, dst, dst_count, src, src_count, len) \
+__async_tx_find_channel(dep, type)
struct dma_chan *
-async_tx_find_channel(struct dma_async_tx_descriptor *depend_tx,
[PATCH 3/4] async_tx: replace 'int_en' with operation preparation flags
Pass a full set of flags to drivers' per-operation 'prep' routines.
Currently the only flag passed is DMA_PREP_INTERRUPT. The expectation is
that arch-specific async_tx_find_channel() implementations can exploit this
capability to find the best channel for an operation.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
---
crypto/async_tx/async_memcpy.c |3 ++-
crypto/async_tx/async_memset.c |3 ++-
crypto/async_tx/async_xor.c| 10 ++
drivers/dma/ioat_dma.c |4 ++--
drivers/dma/iop-adma.c | 20 ++--
include/asm-arm/arch-iop13xx/adma.h| 18 ++
include/asm-arm/hardware/iop3xx-adma.h | 30 +-
include/linux/dmaengine.h | 17 +
8 files changed, 62 insertions(+), 43 deletions(-)
diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
index faca0bc..25dcf33 100644
--- a/crypto/async_tx/async_memcpy.c
+++ b/crypto/async_tx/async_memcpy.c
@@ -52,6 +52,7 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
if (device) {
dma_addr_t dma_dest, dma_src;
+ unsigned long dma_prep_flags = cb_fn ? DMA_PREP_INTERRUPT : 0;
dma_dest = dma_map_page(device->dev, dest, dest_offset, len,
DMA_FROM_DEVICE);
@@ -60,7 +61,7 @@ async_memcpy(struct page *dest, struct page *src, unsigned
int dest_offset,
DMA_TO_DEVICE);
tx = device->device_prep_dma_memcpy(chan, dma_dest, dma_src,
- len, cb_fn != NULL);
+ len, dma_prep_flags);
}
if (tx) {
diff --git a/crypto/async_tx/async_memset.c b/crypto/async_tx/async_memset.c
index 0c94851..8e98ab0 100644
--- a/crypto/async_tx/async_memset.c
+++ b/crypto/async_tx/async_memset.c
@@ -52,12 +52,13 @@ async_memset(struct page *dest, int val, unsigned int
offset,
if (device) {
dma_addr_t dma_dest;
+ unsigned long dma_prep_flags = cb_fn ? DMA_PREP_INTERRUPT : 0;
dma_dest = dma_map_page(device->dev, dest, offset, len,
DMA_FROM_DEVICE);
tx = device->device_prep_dma_memset(chan, dma_dest, val, len,
- cb_fn != NULL);
+ dma_prep_flags);
}
if (tx) {
diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
index fbf113a..80f30bc 100644
--- a/crypto/async_tx/async_xor.c
+++ b/crypto/async_tx/async_xor.c
@@ -41,6 +41,7 @@ do_async_xor(struct dma_device *device,
dma_addr_t *dma_src = (dma_addr_t *) src_list;
struct dma_async_tx_descriptor *tx;
int i;
+ unsigned long dma_prep_flags = cb_fn ? DMA_PREP_INTERRUPT : 0;
pr_debug("%s: len: %zu\n", __FUNCTION__, len);
@@ -56,7 +57,7 @@ do_async_xor(struct dma_device *device,
* in case they can not provide a descriptor
*/
tx = device->device_prep_dma_xor(chan, dma_dest, dma_src, src_cnt, len,
-cb_fn != NULL);
+dma_prep_flags);
if (!tx) {
if (depend_tx)
dma_wait_for_async_tx(depend_tx);
@@ -64,7 +65,7 @@ do_async_xor(struct dma_device *device,
while (!tx)
tx = device->device_prep_dma_xor(chan, dma_dest,
dma_src, src_cnt, len,
-cb_fn != NULL);
+dma_prep_flags);
}
async_tx_submit(chan, tx, flags, depend_tx, cb_fn, cb_param);
@@ -264,6 +265,7 @@ async_xor_zero_sum(struct page *dest, struct page
**src_list,
if (device) {
dma_addr_t *dma_src = (dma_addr_t *) src_list;
+ unsigned long dma_prep_flags = cb_fn ? DMA_PREP_INTERRUPT : 0;
int i;
pr_debug("%s: (async) len: %zu\n", __FUNCTION__, len);
@@ -274,7 +276,7 @@ async_xor_zero_sum(struct page *dest, struct page
**src_list,
tx = device->device_prep_dma_zero_sum(chan, dma_src, src_cnt,
len, result,
- cb_fn != NULL);
+ dma_prep_flags);
if (!tx) {
if (depend_tx)
dma_wait_for_async_tx(depend_tx);
@@ -282,7 +284,7 @@ async_xor_zero_sum(struct page *dest, struct page
**src_list,
while (!tx)
tx =
Re: compat_sys_times() bogus until jiffies >= 0.
David Miller <[EMAIL PROTECTED]> writes: > Only on x86 platforms. Sparc, IA64, MIPS, powerpc, etc. all get this > case right. Do they for 32bit kernels or for 64bit userland? > Yes it's another unfortunate side effect of how error status is > indicated for x86 system calls. Maybe I'm dense, but doesn't all the kernel code pass it the same way as the x86 syscall code? For your proposal you would need a separate error bit coming out of the sys_* to handle this case. Basically rewrite all code that ever returns errors in the kernel. Or do I miss something? Or are you talking about solving it only for 32bit compat emulation on 64bit kernels? There it would be possible, but only doing it there and not on native 32bit systems wouldn't seem clean to me. At least on x86-64 the compat code's (near) only goal in live is to be as compatible to 32it as possible not better. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On 12/21/2007 07:28 PM, Andi Kleen wrote: > Ingo Molnar <[EMAIL PROTECTED]> writes: > >> Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop >> relies on it, people use it every day to monitor memory consumption. > > It's definitely not a stable ABI. slabtop tends to exit without any > error message on any slabinfo version number increase and I've seen > that happen several times in not so old kernels. > > Requiring just another slabtop update isn't really a big deal. > > Also it's not that it's a critical functionality like udev. > There's also Documentation/vm/slabinfo.c, which really belongs in some kind of 'kernel utilities' package. Since it's so intimately tied to kernel version I don't think it belongs in util-linux. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
Ingo Molnar <[EMAIL PROTECTED]> writes: > Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop > relies on it, people use it every day to monitor memory consumption. It's definitely not a stable ABI. slabtop tends to exit without any error message on any slabinfo version number increase and I've seen that happen several times in not so old kernels. Requiring just another slabtop update isn't really a big deal. Also it's not that it's a critical functionality like udev. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/mmap: Remove sparse-warning (NULL as 0).
On Sat, 8 Dec 2007, Richard Knutsson wrote: > Fixing: > CHECK mm/mmap.c > mm/mmap.c:1623:29: warning: Using plain integer as NULL pointer > mm/mmap.c:1623:29: warning: Using plain integer as NULL pointer > mm/mmap.c:1944:29: warning: Using plain integer as NULL pointer > > Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]> > --- > Added by: 8869477a49c3e99def1fcdadd6bbc407fea14b45 (Linus' tree) > Compile-tested on i386 with all[yes|mod|no]config. Thanks, applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6.git#for-akpm - James -- James Morris <[EMAIL PROTECTED]> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-2.6.24-rcX regression / xserver-xorg-video-intel / Q35
Hi! I'm running an Intel DQ35JO mainboard (Q35 chipset, Q6600 CPU) and I am observing a regression with linux-2.6.24-rc1 through -rc6 (linux-2.6.git as of today, ea67db4cdbbf7f4e74150e71da0984e25121f500). The last working version is 2.6.24-rc1. The system is running debian unstable (current) using xserver-xorg-video-intel 2.2.0-1 So what is the actual problem: It seems to be related to the way how the iommu/gart is used for memory allocation of the framebuffer memory. Xorg starts just as it should, but the lower part of the screen is completely gobbled. I suppose the lower part of the screen is actually showing off-screen memory at some completely differnt location. Interestingly, the mouse cursor is superimposed on top of the garbage (and it is not distorted). The visible effect can be observed at the following screenshot: http://ganesha.gnumonks.org/~laforge/tmp/2624rc_xorg_intel.jpg lspci: 00:00.0 Host bridge: Intel Corporation Unknown device 29b0 (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Unknown device 29b2 (rev 02) 00:02.1 Display controller: Intel Corporation Unknown device 29b3 (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Unknown device 29b2 (rev 02) (prog-if 00 [VGA]) Subsystem: Intel Corporation Unknown device 4f4a Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at e038 (32-bit, non-prefetchable) [size=512K] I/O ports at 2430 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at e020 (32-bit, non-prefetchable) [size=1M] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corporation Unknown device 29b3 (rev 02) Subsystem: Intel Corporation Unknown device 4f4a Flags: bus master, fast devsel, latency 0 Memory at e030 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 Please let me know if I should provide more details. I'm also happy to test any patches :) Cheers, -- - Harald Welte <[EMAIL PROTECTED]> http://gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] udf: remove wrong prototype of udf_readdir
On Fri, 21 Dec 2007 16:55:03 +0100 Marcin Slusarz <[EMAIL PROTECTED]> wrote: > sparse generated: > fs/udf/dir.c:78:5: warning: symbol 'udf_readdir' was not declared. Should it > be static? > there are 2 different prototypes of udf_readdir - remove them and move > code around to make it still compile Drat. I just applied six udf patches from you and now we have a new patch series of only five with no indication what changed. I guess I really do need to apply my backlog in reverse time order. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On 12/21/2007 06:54 PM, Christoph Lameter wrote: > > SLUB: Improve hackbench speed > > Increase the mininum number of partial slabs to keep around and put > partial slabs to the end of the partial queue so that they can add > more objects. > > Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> > You forgot to update the commit message. Should be: Put partial slabs to the end of the partial queue so that they can add more objects. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] USB Kconfig: Declutter USB Kconfig Menu
> >Propose new layout as follows: > > Yes, this has been done before in a lot of places, and attempts to > clean up more menus is always welcome. > > Try to use 'menuconfig' objects so people can disable a whole menu > at once without having to enter it, e.g. that USB Gadget thing down > there. Notice that this whole menu is for "Host-side USB", except for that gadget stuff. That might usefully be labeled as "Peripheral-side USB". For that matter, it could be moved up a level in the menu, so the top level driver menu has two USB entries: Host side, and Peripheral side. The driver stacks are independent of each other, except for common data structures like what's in the header file. I think there's no real point, other than history, to having both sides share the same menu. - Dave > > ┌─┐ > > │ --- USB support │ > > │ <*> Support for Host-side USB ---> │ > > │ USB Host Controller Drivers ---> │ > > │ USB Device Class drivers --->│ > > │ --- NOTE: USB_STORAGE needs SCSI, and 'SCSI disk support' may │ > > │ --- also be needed; see USB_STORAGE Help for more information │ > > │ <*> USB Mass Storage support --->│ > > │ [ ] The shared table of common (or usual) storage devices │ > > │ [ ] USB Monitor │ > > │ USB Serial Converter support --->│ > > │ USB DSL modem support ---> │ > > │ USB Imaging devices ---> │ > > │ USB Miscellaneous drivers ---> │ > > │ USB Gadget Support ---> │ > > │ │ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Sat, 22 Dec 2007, Ingo Molnar wrote: > and the regression seems to be largely fixed! Not only is the hackbench > one fixed, but mmap shows an above-noise improvement as well. > > Acked-by: Ingo Molnar <[EMAIL PROTECTED]> Well lets use the version attached to this patch. It turns out that it is not important to increase the number of partial slabs. Just putting the slab onto the tail of the list does it. > And i hereby nominate Pekka as SLUB/SLAB co-maintainer and spokesperson > ;-) He is already the co-maintainer of the slab allocators. See the MAINTAINERS file. SLUB: Improve hackbench speed Increase the mininum number of partial slabs to keep around and put partial slabs to the end of the partial queue so that they can add more objects. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/slub.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) Index: linux-2.6/mm/slub.c === --- linux-2.6.orig/mm/slub.c2007-12-21 14:30:11.096324462 -0800 +++ linux-2.6/mm/slub.c 2007-12-21 15:10:17.611022381 -0800 @@ -1611,12 +1611,12 @@ checks_ok: goto slab_empty; /* -* Objects left in the slab. If it -* was not on the partial list before -* then add it. +* Objects left in the slab. If it was not on the partial list before +* then add it. Add it to the end since there is only a single object +* which would make slab_alloc inefficient. */ if (unlikely(!prior)) - add_partial(get_node(s, page_to_nid(page)), page); + add_partial_tail(get_node(s, page_to_nid(page)), page); out_unlock: slab_unlock(page); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, 21 Dec 2007, Ingo Molnar wrote: > I'm really getting worried that you are apparently incapable of grasping > such _SIMPLE_ concepts. Who the heck cares whether you put in zeros or > whatever else in some of the fields? People use it to know how many > objects are allocated and sure SLUB knows that count, sheesh. How on > earth can you come up with a lame excuse like that? You dont like the > 'SLAB' portion of the name perhaps? Is it NIH again? NIH? I wrote major portions of SLAB. I would be hating my own product. Could you get the facts straight at some point? This is getting weird. > Really, if your behavior is representative of how our SLAB allocator > will be maintained in the future then i'm very, very worried :-( You > ignore and downplay clear-cut regressions, you insult and attack > testers, you are incredibly stupid about user ABIs (or pretend to be so) > and you distort and mislead all the way. What will you be able to do in > the much less clear-cut cases?? I analyzed the issue and argued that the issues that one test showed in SLUB is a really special case and then you conclude that I ignore all regressions? I have addressed and responded to all reports of regressions that came to me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
Hi, On Dec 22, 2007 1:17 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > yep, and i ran a quick comparison test on a 2-core box with 3 kernels: > > [ best of 5 runs in a row which had a relative jitter of less than 10% ] > > MIN v2.6.24.slab v2.6.24.slub v2.6.24.slub.fix > -- >mmap:429.00402.00 ( -6%)385.00 (-10%) > select: 11.38 10.46 ( -8%) 11.41 ( 0%) > proc-exec:121.52116.77 ( -3%)120.77 ( 0%) > proc-fork:106.84106.19 ( 0%)107.92 ( 1%) >syscall-open: 3.09 3.13 ( 1%) 3.25 ( 4%) >hackbench-50: 2.85 3.47 ( 21%) 2.88 ( 1%) > > and the regression seems to be largely fixed! Not only is the hackbench > one fixed, but mmap shows an above-noise improvement as well. > > Acked-by: Ingo Molnar <[EMAIL PROTECTED]> I thought it might be a bug but couldn't figure it out. The patch looks good to me too, Christoph. Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]> On Dec 22, 2007 1:17 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > And i hereby nominate Pekka as SLUB/SLAB co-maintainer and spokesperson > ;-) Heh, thanks, but grep me from MAINTAINERS some day, Ingo :-). Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] add task handling notifier: base definitions
"Jan Beulich" <[EMAIL PROTECTED]> writes: > This is the base patch, adding notification for task creation and > deletion. I like the basic concept. At some point I suspect we'll even need a per task dynamic data allocator, that would remove even more cruft. Could you change the block notifier calls first to not take their lock when there is nothing in the list (the common case)? It is weird that they don't already do this, but they should definitely here. I think the use of the blocking/atomic notifiers needs some comment. I think I understand why you did it -- exit atomic because sleeping in exit can be illegal and blocking for fork to allow GFP_KERNEL allocations -- but that should be documented somewhere. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, 21 Dec 2007 23:54:13 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > * Christoph Lameter <[EMAIL PROTECTED]> wrote: > > > On Fri, 21 Dec 2007, Peter Zijlstra wrote: > > > > > BTW, does /proc/slabinfo exist again? I thought we set that as a > > > requirement for SLUB to be the default and a full replacement for > > > SLAB. > > > > Well the information that would be exposed in /proc/slabinfo would > > only be faked up stuff from SLUB. The queues that are described in > > /proc/slabinfo do not exist f.e. (tunables do not make sense) and > > there are more details available via /sys/kernel/slab. > > Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. That would be really bad. /proc/slabinfo intimately exposes implementation-specific internals and strictly speaking should never have been introduced. Obviously that isn't a _practical_ position, but there are no easy solutions here. We don't want to have to drag a pile of be-compatible-with-slab gunk along with us for ever. > slabtop > relies on it, people use it every day to monitor memory consumption. slabtop needs to be changed asap. Possibly we could look at adding some interrim make-it-look-like-slab hack into slub.c for a couple of releases but no longer. If we'd updated slabtop six months ago this issue wouldn't have arisen now. But we didn't do that. We're quite bad at this sort of thing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
* Linus Torvalds <[EMAIL PROTECTED]> wrote: > And now, can the people who made the problem reports and complained > about SLUB please test the patch - the ball is now in your court! yep, and i ran a quick comparison test on a 2-core box with 3 kernels: [ best of 5 runs in a row which had a relative jitter of less than 10% ] MIN v2.6.24.slab v2.6.24.slub v2.6.24.slub.fix -- mmap:429.00402.00 ( -6%)385.00 (-10%) select: 11.38 10.46 ( -8%) 11.41 ( 0%) proc-exec:121.52116.77 ( -3%)120.77 ( 0%) proc-fork:106.84106.19 ( 0%)107.92 ( 1%) syscall-open: 3.09 3.13 ( 1%) 3.25 ( 4%) hackbench-50: 2.85 3.47 ( 21%) 2.88 ( 1%) and the regression seems to be largely fixed! Not only is the hackbench one fixed, but mmap shows an above-noise improvement as well. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> And i hereby nominate Pekka as SLUB/SLAB co-maintainer and spokesperson ;-) Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
From: Ingo Molnar <[EMAIL PROTECTED]> Date: Fri, 21 Dec 2007 23:54:13 +0100 > Really, if your behavior is representative of how our SLAB allocator > will be maintained in the future then i'm very, very worried :-( Actually, to the contrary, I actually think Christoph responds to every problem I've ever reported to him about his per-cpu counters work and SLUB much better than most people who call themselves "maintainers" around here. And I say that without any reservations. He doesn't deserve the ad-hominem attacks he is getting today, because he does resolve every problem reported to him. The guy wrote test cases, he analyzed every problem, he wrote test patches, and he doesn't stop doing any of that until the issue really is reported as resolved by the testers. I'll take Christoph as the implementor and maintainer of anything, any day of the week. He rocks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] cciss: export more attributes to sysfs (repost)
On Fri, 14 Dec 2007 16:17:44 -0600
Mike Miller <[EMAIL PROTECTED]> wrote:
> Patch 1 of 3
>
> Sorry to take so long to repost.
>
> This patch exports more attributes to /sys so we can work work better with
> udev. Some distros use unique_id among other attributes. This patch attempts
> to provide that and other attributes to reveal more information about cciss
> devices in /sys. It's also an effort to be more sysfs friendly.
> Please consider this for inclusion.
>
I'm getting some deja vu here. I'm sure I already commented on some of
these things?
>
> diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
> index 7d70496..54080e6 100644
> --- a/drivers/block/cciss.c
> +++ b/drivers/block/cciss.c
> @@ -229,20 +229,485 @@ static inline CommandList_struct
> *removeQ(CommandList_struct **Qptr,
> return c;
> }
>
> +static inline int find_drv_index(int ctlr, drive_info_struct *drv){
> +int i;
> +for (i=0; i < CISS_MAX_LUN; i++) {
> +if (hba[ctlr]->drv[i].LunID == drv->LunID)
> +return i;
> +}
> +return i;
> +}
pleeeze always feed all diffs through scripts/checkpatch.pl. Twice.
This function has multiple coding-style mistakes.
It is also far too large to be inlined.
> #include "cciss_scsi.c" /* For SCSI tape support */
>
> +#define ENG_GIG 10
> +#define ENG_GIG_FACTOR (ENG_GIG/512)
> #define RAID_UNKNOWN 6
> +static const char *raid_label[] = { "0", "4", "1(1+0)", "5", "5+1", "ADG",
> + "UNKNOWN"};
> +
> +
> +static spinlock_t sysfs_lock = SPIN_LOCK_UNLOCKED;
checkpatch would have informed you about this mistake as well.
> +static void cciss_sysfs_stat_inquiry(int ctlr, int logvol,
> + int withirq, drive_info_struct *drv)
> +{
> + int return_code;
> + InquiryData_struct *inq_buff;
> +
> + /* If there are no heads then this is the controller disk and
> + * not a valid logical drive so don't query it.
> + */
> + if (!drv->heads)
> + return;
> +
> + inq_buff = kzalloc(sizeof(InquiryData_struct), GFP_KERNEL);
> + if (!inq_buff) {
> + printk(KERN_ERR "cciss: out of memory\n");
This failure gets dropped on the floor. Is there really no need to report
it? Will the driver still correctly function even thoug this function
didn't do anything?
> + goto err;
> + }
> +
> + if (withirq)
> + return_code = sendcmd_withirq(CISS_INQUIRY, ctlr,
> + inq_buff, sizeof(*inq_buff), 1, logvol ,0, TYPE_CMD);
> + else
> + return_code = sendcmd(CISS_INQUIRY, ctlr, inq_buff,
> + sizeof(*inq_buff), 1, logvol , 0, NULL, TYPE_CMD);
> + if (return_code == IO_OK) {
> + memcpy(drv->vendor, _buff->data_byte[8], 8);
> + drv->vendor[8]='\0';
> + memcpy(drv->model, _buff->data_byte[16], 16);
> + drv->model[16] = '\0';
> + memcpy(drv->rev, _buff->data_byte[32], 4);
> + drv->rev[4] = '\0';
> + } else { /* Get geometry failed */
> + printk(KERN_WARNING "cciss: inquiry for VPD page 0 failed\n");
> + }
> +
> + if (withirq)
> + return_code = sendcmd_withirq(CISS_INQUIRY, ctlr,
> + inq_buff, sizeof(*inq_buff), 1, logvol ,0x83, TYPE_CMD);
> + else
> + return_code = sendcmd(CISS_INQUIRY, ctlr, inq_buff,
> + sizeof(*inq_buff), 1, logvol , 0x83, NULL, TYPE_CMD);
> +
> + if (return_code == IO_OK) {
> + memcpy(drv->uid, _buff->data_byte[8], 16);
> + } else { /* Get geometry failed */
> + printk(KERN_WARNING "cciss: inquiry for VPD page 83 failed\n");
> + }
> +
> + kfree(inq_buff);
> +err:
> + drv->vendor[8] = '\0';
> + drv->model[16] = '\0';
> + drv->rev[4] = '\0';
> +
> +}
> +
> +static ssize_t cciss_show_raid_level(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct drv_dynamic *d;
> + drive_info_struct *drv;
> + ctlr_info_t *h;
> + unsigned long flags;
> + int raid;
> +
> + d = container_of(dev, struct drv_dynamic, dev);
> + spin_lock(_lock);
> + if (!d->disk) {
> + spin_unlock(_lock);
> + return -ENOENT;
> + }
> +
> + h = get_host(d->disk);
> +
> + spin_lock_irqsave(CCISS_LOCK(h->ctlr), flags);
> + if (h->busy_configuring) {
> + spin_unlock_irqrestore(CCISS_LOCK(h->ctlr), flags);
> + spin_unlock(_lock);
> + return snprintf(buf, 30, "Device busy configuring\n");
> + }
The above code snippet gets repeated again and again and again. As I
suggested last time: can this be fixed?
> + drv = d->disk->private_data;
> + if ((drv->raid_level < 0) || (drv->raid_level) > 5)
> + raid = RAID_UNKNOWN;
> + else
> + raid = drv->raid_level;
> +
> +
Re: list corruption on ib_srp load in v2.6.24-rc5
On Fri, 2007-12-21 at 16:52 -0500, David Dillow wrote: > I'm getting the following oops when doing the following commands: > > modprobe ib_srp > > rmmod ib_srp > modprobe ib_srp > > > I'm going to try and track down how the list is getting corrupted; it > looks like attribute_container_list in > drivers/base/attribute_container.c is the one getting corrupted. Ok, found the culprit, now to figure out the motive and fix it. ib_srp's srp_cleanup_module calls srp_release_transport(), which calls transport_container_unregister() for the rport_attr_cont member of struct srp_internal. That last unregister call is returning -EBUSY, but it gets ignored, and the list node gets erased (or just reused) when the module's text/memory is free'd. Now, to see if ib_srp should be waiting for everything to be destroyed before calling srp_release_transport(), or if it is just not removing some attributes properly. That's a next week thing if no one beats me to it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] PCI: use dev_printk in x86 quirk messages
On Fri, Dec 21, 2007 at 11:40:53PM +0100, Ingo Molnar wrote: > > * Greg KH <[EMAIL PROTECTED]> wrote: > > > > > arch/x86/kernel/quirks.c | 42 > > > > ++ > > > > arch/x86/pci/fixup.c | 22 +++--- > > > > > > That made it hard. Arguably one file is PCI tree and the other is > > > x86 tree. > > > > Hm, as traditionally we haven't had such an active x86 maintainer, > > I've handled most of the pci quirk type stuff that people have sent to > > me in the past :) > > > > But, now that we have more enthusiastic developers, I can change this. > > If you want me to cut portions of the patch up, I'll be glad to do so, > > just let me know. > > > > It's easy for me when merging, as our tools can handle it just fine, > > but Andrew is the one with the big problems, so we should probably > > shake it out on our end first... > > > > Ingo, what is easiest for you to do? As I use quilt, I can very > > simply cut a portion of the patch up, or drop it entirely. > > There's one patch right now in x86.git that affects > arch/x86/kernel/quirks.c and arch/x86/pci/fixup.c - the one from Bjorn. > (find below) That's the same one I have :) > Are your quirks (and other arch/x86) patches nicely standalone? If yes > then we could pick them up just fine - patch-bomb me or send a tarball > or mbox of the patches - whichever is the most convenient for you. (we > too use quilt as the main repository) They are usually mixed up with the other pci patches in my pci tree: http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-02-pci/ > but if there's some dependency on continuing pci/driver infrastructure > you might be working on then it would be better for you to carry them. > Or if you'd just like to have Bjorn's patch in one piece. Tell me and > i'll drop the changes below from x86.git. > > In any case, both variants would be fine for us - the important thing is > to not drop any of the patches on the floor :) How about you drop this one patch, and I'll keep it, as it goes along with the other 2 patches in his series, and I'll make sure to check if I have future pci quirk patches that affect the x86/ directory. Sound reasonable? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
* Christoph Lameter <[EMAIL PROTECTED]> wrote: > if (unlikely(!prior)) > - add_partial(get_node(s, page_to_nid(page)), page); > + add_partial_tail(get_node(s, page_to_nid(page)), page); FYI, this gives me: mm/slub.c: In function 'kfree': mm/slub.c:2604: warning: passing argument 3 of 'slab_free' discards qualifiers from pointer target type looks harmless though at first sight. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allow Kconfig to set default mmap_min_addr protection
On Dec 21 2007 14:35, Greg KH wrote: >> >> >I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is >> >> >base 10 as well >> >> >> >> sysfs is autobase, i.e. echo "0xb000" >/sys/foo will Do The Right Thing. >> > >> >yes but if you cat /proc/sys/vm/mmap_min_addr, it returns in base 10. >> >> sysfs should probably be tuned to output it in a preferred base. > >Again, this is sysctl, not sysfs. two very different things... > Argh... :) Just shows that /proc is the wrong place for system variables. Well, module_params(integer) are autobase, and that's all I needed so far :-D -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
* Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Fri, 21 Dec 2007, Peter Zijlstra wrote: > > > BTW, does /proc/slabinfo exist again? I thought we set that as a > > requirement for SLUB to be the default and a full replacement for > > SLAB. > > Well the information that would be exposed in /proc/slabinfo would > only be faked up stuff from SLUB. The queues that are described in > /proc/slabinfo do not exist f.e. (tunables do not make sense) and > there are more details available via /sys/kernel/slab. Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop relies on it, people use it every day to monitor memory consumption. I'm really getting worried that you are apparently incapable of grasping such _SIMPLE_ concepts. Who the heck cares whether you put in zeros or whatever else in some of the fields? People use it to know how many objects are allocated and sure SLUB knows that count, sheesh. How on earth can you come up with a lame excuse like that? You dont like the 'SLAB' portion of the name perhaps? Is it NIH again? Really, if your behavior is representative of how our SLAB allocator will be maintained in the future then i'm very, very worried :-( You ignore and downplay clear-cut regressions, you insult and attack testers, you are incredibly stupid about user ABIs (or pretend to be so) and you distort and mislead all the way. What will you be able to do in the much less clear-cut cases?? Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, 21 Dec 2007, Christoph Lameter wrote: > Actually thanks for pointing that out Pekka Here is a patch that takes > the regression almost completely away (Too much jetlag combined with flu > seems to have impaired my thinking I should have seen this earlier). I > still need to run my slab performance tests on this. But hackbench > improves. > > > SLUB: Improve hackbench speed > > Increase the mininum number of partial slabs to keep around and put > partial slabs to the end of the partial queue so that they can add > more objects. > > Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> > FYI, I'm currently on holiday till Jan 2cd, and I also lost access to the machine I did the orignal benchmarks on. But I'll try to reserve it again after the New Year, and I will run the benchmarks including this patch and report my findings. Thanks, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, 21 Dec 2007, Christoph Lameter wrote: > > Actually thanks for pointing that out Pekka Here is a patch that takes > the regression almost completely away Now *this* is what I wanted to see - rather than argue against other peoples performance regression reports, an actual patch that acknowledges the problem. Thanks. And now, can the people who made the problem reports and complained about SLUB please test the patch - the ball is now in your court! Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, 21 Dec 2007, Christoph Lameter wrote: > > It obviously can replace it and has replaced it for awhile now. No. If there are 6% performance regressions on TPC-C, then it CAN NOT replace it! > Well still SLUB is really superior to SLAB in many ways > > - SLUB is performance wise much faster than SLAB. No. Christoph, statements like this is *exactly* why I don't think SLUB can make it. You're closing your eyes to real performace *regression* reports, and then you claim thast SLUB is faster, because you find your own microbenchmarks that show so for specific loads. But those specific loads are apparetly never the issue. So stop saying that SLUB is "much faster", as long as hackbench shows that that is simply NOT THE CASE. It doesn't matter one whit if SLUB is lots faster, if it's faster for cases that never matter. So far, I don't think we've *ever* seen any actual benchmarks that involve any kind of real use where SLUB is really faster, and we have some major examples of SLUB being disastrously slower! Your special-case kmalloc performance tests don't matter, when real user programs show the exact opposite effect. And the fact that you dismiss those real user programs just because you have your own test harness is why I'm ready to throw in the towel on SLUB. I don't mind performance regressions, but I *do* mind performance regressions when the main author then says "look, a helicopter!" and points to some totally different thing and claims that the performance regression doesn't even exist! Because those kinds of performance regressions never get fixed, because they are ignored. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: INITIO scsi driver fails to work properly
On Fri, 2007-12-21 at 17:43 -0500, Chuck Ebbert wrote: > On 12/21/2007 04:03 PM, James Bottomley wrote: > > On Fri, 2007-12-21 at 14:30 -0500, Chuck Ebbert wrote: > >> On 12/19/2007 03:48 AM, Filippos Papadopoulos wrote: > >>> On Dec 17, 2007 2:18 PM, Boaz Harrosh <[EMAIL PROTECTED]> wrote: > I have found one problem. Please try patch [2] below and report. > If it still fails try to enable debugging by setting with patch [1] > these values at top of drivers/scsi/initio.c. And send dmsgs. > > Boaz > > >>> > >>> I tried patch[2] (addition of sg++) at 2.6.24-rc5-mm1 but the > >>> system hangs after some seconds when the initio driver loads. > >>> I will try patch[1] next week to see what happens. > >>> > >>> Would it be better to open a bug report at bugzilla? > >>> > >> There is also a Fedora bug report against 2.6.23. The user has > >> applied commit e9e42faf47255274a1ed0b9bf1c46118023ec5fa from > >> 2.6.24-rc plus the two additional fixes under discussion and it > >> hangs for him too. > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=390531 > > > > It really sounds like there's some problem applying the patches. The > > consistent report throughout is this one: > > > > initio: I/O port range 0x0 is busy. > > > > Which should be fixed by 99f1f534922a2f2251ba05b14657a1c62882a80e. I > > didn't actually find that in the bug thread anywhere, but maybe I missed > > it? > > > > The "I/O port 0" bug just prints the message and the system continues > to run. It's only after that is fixed that the system just hangs on > boot shortly after loading the driver. That should happen unless the PCI BAR is genuinely misconfigured; it's saying we got zero when we requested the starting address of BAR0. What does lspci -vv show for this device? James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
video breaks asus-laptop display switching
Hi, With 2.6.23 or newer (including 2.6.24-rc6) kernels, writing to the /sys/devices/platform/asus-laptop/display file does not do anything: Cold boot to single user, then connect an external monitor # cat /sys/devices/platform/asus-laptop/display 1 OK, only the built in LCD is enabled. Try to enable the external monitor as well: # echo 3 > /sys/devices/platform/asus-laptop/display still no image on the external. # cat /sys/devices/platform/asus-laptop/display 1 Still "1", not the "3" we wrote. On the other hand if I boot with an external monitor attached, the "display" file always contains 3, even after writing 1 there, and there is image on both monitors. In 2.6.22 I had to load asus-laptop by hand, but then display switching worked nicely. I've noticed that if I do # rmmod video display switching starts working again with the newer kernels. The "video" module was auto-loaded on my system in 2.6.22, but did not cause the conflict. This is an ASUS Z71V based notebook (detected as M7V). Regards, Andrei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: INITIO scsi driver fails to work properly
On 12/21/2007 04:03 PM, James Bottomley wrote: > On Fri, 2007-12-21 at 14:30 -0500, Chuck Ebbert wrote: >> On 12/19/2007 03:48 AM, Filippos Papadopoulos wrote: >>> On Dec 17, 2007 2:18 PM, Boaz Harrosh <[EMAIL PROTECTED]> wrote: I have found one problem. Please try patch [2] below and report. If it still fails try to enable debugging by setting with patch [1] these values at top of drivers/scsi/initio.c. And send dmsgs. Boaz >>> >>> I tried patch[2] (addition of sg++) at 2.6.24-rc5-mm1 but the >>> system hangs after some seconds when the initio driver loads. >>> I will try patch[1] next week to see what happens. >>> >>> Would it be better to open a bug report at bugzilla? >>> >> There is also a Fedora bug report against 2.6.23. The user has >> applied commit e9e42faf47255274a1ed0b9bf1c46118023ec5fa from >> 2.6.24-rc plus the two additional fixes under discussion and it >> hangs for him too. >> >> https://bugzilla.redhat.com/show_bug.cgi?id=390531 > > It really sounds like there's some problem applying the patches. The > consistent report throughout is this one: > > initio: I/O port range 0x0 is busy. > > Which should be fixed by 99f1f534922a2f2251ba05b14657a1c62882a80e. I > didn't actually find that in the bug thread anywhere, but maybe I missed > it? > The "I/O port 0" bug just prints the message and the system continues to run. It's only after that is fixed that the system just hangs on boot shortly after loading the driver. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] PCI: use dev_printk in x86 quirk messages
* Greg KH <[EMAIL PROTECTED]> wrote:
> > > arch/x86/kernel/quirks.c | 42 ++
> > > arch/x86/pci/fixup.c | 22 +++---
> >
> > That made it hard. Arguably one file is PCI tree and the other is
> > x86 tree.
>
> Hm, as traditionally we haven't had such an active x86 maintainer,
> I've handled most of the pci quirk type stuff that people have sent to
> me in the past :)
>
> But, now that we have more enthusiastic developers, I can change this.
> If you want me to cut portions of the patch up, I'll be glad to do so,
> just let me know.
>
> It's easy for me when merging, as our tools can handle it just fine,
> but Andrew is the one with the big problems, so we should probably
> shake it out on our end first...
>
> Ingo, what is easiest for you to do? As I use quilt, I can very
> simply cut a portion of the patch up, or drop it entirely.
There's one patch right now in x86.git that affects
arch/x86/kernel/quirks.c and arch/x86/pci/fixup.c - the one from Bjorn.
(find below)
Are your quirks (and other arch/x86) patches nicely standalone? If yes
then we could pick them up just fine - patch-bomb me or send a tarball
or mbox of the patches - whichever is the most convenient for you. (we
too use quilt as the main repository)
but if there's some dependency on continuing pci/driver infrastructure
you might be working on then it would be better for you to carry them.
Or if you'd just like to have Bjorn's patch in one piece. Tell me and
i'll drop the changes below from x86.git.
In any case, both variants would be fine for us - the important thing is
to not drop any of the patches on the floor :)
Ingo
>
Subject: PCI: use dev_printk in x86 quirk messages
From: [EMAIL PROTECTED]
Convert quirk printks to dev_printk().
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
---
arch/x86/kernel/quirks.c | 43 +++
arch/x86/pci/fixup.c | 22 +++---
2 files changed, 34 insertions(+), 31 deletions(-)
Index: linux-x86.q/arch/x86/kernel/quirks.c
===
--- linux-x86.q.orig/arch/x86/kernel/quirks.c
+++ linux-x86.q/arch/x86/kernel/quirks.c
@@ -30,8 +30,8 @@ static void __devinit quirk_intel_irqbal
raw_pci_ops->read(0, 0, 0x40, 0x4c, 2, );
if (!(word & (1 << 13))) {
- printk(KERN_INFO "Intel E7520/7320/7525 detected. "
- "Disabling irq balancing and affinity\n");
+ dev_info(>dev, "Intel E7520/7320/7525 detected; "
+ "disabling irq balancing and affinity\n");
#ifdef CONFIG_IRQBALANCE
irqbalance_disable("");
#endif
@@ -104,14 +104,16 @@ static void ich_force_enable_hpet(struct
pci_read_config_dword(dev, 0xF0, );
rcba &= 0xC000;
if (rcba == 0) {
- printk(KERN_DEBUG "RCBA disabled. Cannot force enable HPET\n");
+ dev_printk(KERN_DEBUG, >dev, "RCBA disabled; "
+ "cannot force enable HPET\n");
return;
}
/* use bits 31:14, 16 kB aligned */
rcba_base = ioremap_nocache(rcba, 0x4000);
if (rcba_base == NULL) {
- printk(KERN_DEBUG "ioremap failed. Cannot force enable HPET\n");
+ dev_printk(KERN_DEBUG, >dev, "ioremap failed; "
+ "cannot force enable HPET\n");
return;
}
@@ -122,8 +124,8 @@ static void ich_force_enable_hpet(struct
/* HPET is enabled in HPTC. Just not reported by BIOS */
val = val & 0x3;
force_hpet_address = 0xFED0 | (val << 12);
- printk(KERN_DEBUG "Force enabled HPET at base address 0x%lx\n",
- force_hpet_address);
+ dev_printk(KERN_DEBUG, >dev, "Force enabled HPET at "
+ "0x%lx\n", force_hpet_address);
iounmap(rcba_base);
return;
}
@@ -142,11 +144,12 @@ static void ich_force_enable_hpet(struct
if (err) {
force_hpet_address = 0;
iounmap(rcba_base);
- printk(KERN_DEBUG "Failed to force enable HPET\n");
+ dev_printk(KERN_DEBUG, >dev,
+ "Failed to force enable HPET\n");
} else {
force_hpet_resume_type = ICH_FORCE_HPET_RESUME;
- printk(KERN_DEBUG "Force enabled HPET at base address 0x%lx\n",
- force_hpet_address);
+ dev_printk(KERN_DEBUG, >dev, "Force enabled HPET at "
+ "0x%lx\n", force_hpet_address);
}
}
@@ -206,8 +209,8 @@ static void old_ich_force_enable_hpet(st
if (val & 0x4) {
val &= 0x3;
Re: Major regression on hackbench with SLUB (more numbers)
Actually thanks for pointing that out Pekka Here is a patch that takes the regression almost completely away (Too much jetlag combined with flu seems to have impaired my thinking I should have seen this earlier). I still need to run my slab performance tests on this. But hackbench improves. SLUB: Improve hackbench speed Increase the mininum number of partial slabs to keep around and put partial slabs to the end of the partial queue so that they can add more objects. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> --- mm/slub.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6/mm/slub.c === --- linux-2.6.orig/mm/slub.c2007-12-21 14:30:11.096324462 -0800 +++ linux-2.6/mm/slub.c 2007-12-21 14:30:33.656441994 -0800 @@ -172,7 +172,7 @@ static inline void ClearSlabDebug(struct * Mininum number of partial slabs. These will be left on the partial * lists even if they are empty. kmem_cache_shrink may reclaim them. */ -#define MIN_PARTIAL 2 +#define MIN_PARTIAL 5 /* * Maximum number of desirable partial slabs. @@ -1616,7 +1616,7 @@ checks_ok: * then add it. */ if (unlikely(!prior)) - add_partial(get_node(s, page_to_nid(page)), page); + add_partial_tail(get_node(s, page_to_nid(page)), page); out_unlock: slab_unlock(page); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allow Kconfig to set default mmap_min_addr protection
On Fri, Dec 21, 2007 at 11:04:19PM +0100, Jan Engelhardt wrote: > > On Dec 21 2007 22:16, Willy Tarreau wrote: > >Hi Jan, > > > >> >> >+config SECURITY_DEFAULT_MMAP_MIN_ADDR > >> >> >+int "Low address space to protect from user allocation" > >> >> > >> >> Hm, should not this be 'hex'? > >> > > >> >I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is > >> >base 10 as well > >> > >> sysfs is autobase, i.e. echo "0xb000" >/sys/foo will Do The Right Thing. > > > >yes but if you cat /proc/sys/vm/mmap_min_addr, it returns in base 10. > > sysfs should probably be tuned to output it in a preferred base. Again, this is sysctl, not sysfs. two very different things... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allow Kconfig to set default mmap_min_addr protection
On Fri, Dec 21, 2007 at 10:10:24PM +0100, Jan Engelhardt wrote: > > On Dec 21 2007 15:31, Eric Paris wrote: > >On Thu, 2007-12-20 at 00:29 +0100, Jan Engelhardt wrote: > >> On Dec 19 2007 16:59, Eric Paris wrote: > >> > > >> >+config SECURITY_DEFAULT_MMAP_MIN_ADDR > >> >+int "Low address space to protect from user allocation" > >> > >> Hm, should not this be 'hex'? > > > >I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is > >base 10 as well > > sysfs is autobase, i.e. echo "0xb000" >/sys/foo will Do The Right Thing. Hm, no, that is not sysfs doing this, and sysfs is not autobase in all places. That is sysctl (/proc/sys/), not sysfs. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[no subject]
[EMAIL PROTECTED] Bcc: Subject: Re: Regarding request for IBM camera patch to be applied to the main tree Reply-To: In-Reply-To: <[EMAIL PROTECTED]> On Fri, Dec 21, 2007 at 03:21:30PM -0600, David Hilvert wrote: > > > http://www.linux-usb.org/ibmcam/ > > > > http://auricle.dyndns.org/xvp610/ > > [Remainder of private e-mail context snipped; message has been blind-CC'ed to > the original recipients. Please CC any replies intended for me.] > > As the author of the second patch noted, I had avoided sending it to lkml due > to the difficulty of determining whether the patch is correct (e.g., having no > ill effect on other cameras), due, in turn, to lack of documentation for this > series of cameras. Perhaps dmitri could comment further on this, if he has > time and access to test on any other cameras that might fall under the 'model > 3' designation (whatever this designation might mean). The (rather old, now) > patch in question (against 2.6.1 or so, and perhaps other versions) follows; > if > I recall correctly, it was designed to minimize change lines rather than > provide for overall clarity, so that a clearer final implementation is > probably > possible. > > > diff -urN linux-2.6.1/drivers/usb/media/ibmcam.c > linux-2.6.1-patched/drivers/usb/media/ibmcam.c > --- linux-2.6.1/drivers/usb/media/ibmcam.cFri Jan 9 00:59:19 2004 > +++ linux-2.6.1-patched/drivers/usb/media/ibmcam.cFri Feb 6 14:54:33 2004 I suggest forward porting it to the latest tree and submit it to the usb video maintainers for inclusion. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] PCI: use dev_printk in x86 quirk messages
On Fri, Dec 21, 2007 at 01:47:35PM -0800, Andrew Morton wrote: > On Tue, 18 Dec 2007 14:58:01 +0100 > Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > Convert quirk printks to dev_printk(). > > > > thanks, applied the x86 bits. > > > > Greg applied it too. Could you guys please sort out some sort of > who-owns-what protocol? > > Thanks. > > > arch/x86/kernel/quirks.c | 42 ++ > > arch/x86/pci/fixup.c | 22 +++--- > > That made it hard. Arguably one file is PCI tree and the other is x86 > tree. Hm, as traditionally we haven't had such an active x86 maintainer, I've handled most of the pci quirk type stuff that people have sent to me in the past :) But, now that we have more enthusiastic developers, I can change this. If you want me to cut portions of the patch up, I'll be glad to do so, just let me know. It's easy for me when merging, as our tools can handle it just fine, but Andrew is the one with the big problems, so we should probably shake it out on our end first... Ingo, what is easiest for you to do? As I use quilt, I can very simply cut a portion of the patch up, or drop it entirely. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, 21 Dec 2007, Peter Zijlstra wrote: > BTW, does /proc/slabinfo exist again? I thought we set that as a > requirement for SLUB to be the default and a full replacement for SLAB. Well the information that would be exposed in /proc/slabinfo would only be faked up stuff from SLUB. The queues that are described in /proc/slabinfo do not exist f.e. (tunables do not make sense) and there are more details available via /sys/kernel/slab. There is a discussion on linux-mm with some of the people working on tools to make these to use the information that SLUB provides. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, 21 Dec 2007, Pekka Enberg wrote: > Christoph, did you see Steven's oprofile results for the hackbench > runs (http://lkml.org/lkml/2007/12/8/198)? Any ideas why we're hitting > add_partial like crazy? Hmmm... SLUB is cycling through partial slabs. If it gets fed objects with a single free object from the free list again and again then this is the behavior that one would see. The worst case scenario would be. 1. Processor 0 gets slab with one free entry from the partial list. 2. Processor 0 allocates object and deactivates the slab since it is full. 3. Processor 1 frees the object and finds that it was not on the partial list since there were no free objects. Call put_partial() 4. processor 0 gets slab with one free entry from the partial list. If we would make the partial list a mininum size (which is already done through MIN_PARTIAL maybe just increase it) then we may be able to avoid this particular case. Also we could make sure that the slab is not put at the beginning of the partial list on free in order to increase the time that the slab spends on the partial list. That way it will gather more objects before it is picked up. H... This is a bit different from what I got to here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] list corruption on ib_srp load in v2.6.24-rc5
> I'm getting the following oops when doing the following commands: > > modprobe ib_srp > > rmmod ib_srp > modprobe ib_srp > > > I'm going to try and track down how the list is getting corrupted; it > looks like attribute_container_list in > drivers/base/attribute_container.c is the one getting corrupted. > > Before I get too far into this, has anyone seen this one before? I > looked at 'git diff v2.6.24-rc4..' and didn't see any changes that would > stand out as fixing it. I haven't seen this, but I actually haven't done much srp testing with post-2.6.23 kernels. From a quick skim through the code, I would guess that one of the calls to transport_container_unregister() in srp_release_transport() (which is called one module unload) is failing and leaving something bogus on the attribute_container_list. This could because the underlying call to attribute_container_unregister() fails because the k_list is not empty. I don't know if this is some sort of leak in the ib_srp driver, or something broken elsewhere... - R. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is there any IBM SSA Adapter driver available in Linux????
Hi All, I have now free IBM H70 with old SSA Array (1 TB discs) and would like use it as a samba share. Everythink is working except the SSA card accessing the array: 0001:40:0b.0 SSA: IBM SSA Adapter [Advanced SerialRAID/X] (rev 06) Is there driver available for this card? Thanks a lot for reply, I am searching more a day without any success Thanks a lot and Merry Christmas! Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, 2007-12-21 at 23:16 +0100, Peter Zijlstra wrote: > On Fri, 2007-12-21 at 14:11 -0800, Christoph Lameter wrote: > > On Fri, 21 Dec 2007, Linus Torvalds wrote: > > > > > If you aren't even motivated to fix the problems that have been reported, > > > then SLUB isn't even a _potential_ solution, it's purely a problem, and > > > since I am not IN THE LEAST interested in having three different > > > allocators around, SLUB is going to get axed. > > > > Not motivated? I have analyzed the problem in detail and when it comes > > down to it there is not much impact that I can see in real life > > applications. I have always responded to the regression reported also via > > TPC-C. > > But you are dismissing the hackbench regression, which is not a small > one. It runs an astonishing 10x slower. > BTW, does /proc/slabinfo exist again? I thought we set that as a requirement for SLUB to be the default and a full replacement for SLAB. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, 2007-12-21 at 14:11 -0800, Christoph Lameter wrote: > On Fri, 21 Dec 2007, Linus Torvalds wrote: > > > If you aren't even motivated to fix the problems that have been reported, > > then SLUB isn't even a _potential_ solution, it's purely a problem, and > > since I am not IN THE LEAST interested in having three different > > allocators around, SLUB is going to get axed. > > Not motivated? I have analyzed the problem in detail and when it comes > down to it there is not much impact that I can see in real life > applications. I have always responded to the regression reported also via > TPC-C. But you are dismissing the hackbench regression, which is not a small one. It runs an astonishing 10x slower. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, 21 Dec 2007, Linus Torvalds wrote: > If you aren't even motivated to fix the problems that have been reported, > then SLUB isn't even a _potential_ solution, it's purely a problem, and > since I am not IN THE LEAST interested in having three different > allocators around, SLUB is going to get axed. Not motivated? I have analyzed the problem in detail and when it comes down to it there is not much impact that I can see in real life applications. I have always responded to the regression reported also via TPC-C. There is still no answer to my post at http://lkml.org/lkml/2007/10/27/245 SLAB has similar issues when freeing to remote nodes under NUMA. Its even worse since the lock is not per slab page but per slab cache. The alien caches that are then used have one lock per node. > In other words, here's the low-down: > > a) either SLUB can replace SLAB, or SLUB is going away > > This isn't open for discussion, Christoph. This was the rule back when > it got merged in the first place. It obviously can replace it and has replaced it for awhile now. > b) if SLUB performs worse than SLAB on real loads (TPC-C certainly being > one, and while hackbench may be borderline, it's certainly less > borderline than others), then SLUB cannot replace SLAB. Looks like I need to find someone to get that going here to be able to test under it. > c) If you aren't even interested in trying to fix it and are ignoring > the reports, there is not even a _potential_ for SLUB for getting over > these problems, and I should disable it and we should get over it as > soon as possible, and this whole discussion is pretty much ended. I have looked at this issue under various circumstances for the last week. Nothing really convinced me that this is so serious. Could not figure out if its really worth anything about but if you put it that way then of course it is. > The main reason for SLUB in the first place was SGI concerns. You seem to > think that _only_ SGI concerns matter. Wrong. If SLUB remains a SGI-only > thing and you don't fix it for other users, then SLUB gets reverted from > the standard kernel. The reason for SLUB was dysfunctional behavior of SLAB in many areas. It was not just SGI's concerns that drove it. > That's all. And it's not really worth discussing. Well still SLUB is really superior to SLAB in many ways - SLUB is performance wise much faster than SLAB. This can be more than a factor of 10 (case of concurrent allocations / frees on multiple processors). See http://lkml.org/lkml/2007/10/27/245 - Single threaded allocation speed is up to double that of SLAB - Remote freeing of objectcs in a NUMA systems is typically 30% faster. - Debugging on SLAB is difficult. Requires recompile of the kernel and the resulting output is difficult to interpret. SLUB can apply debugging options to a subset of the slabcaches in order to allow the system to work with maximum speed. This is necessary to detect difficult to reproduce race conditions. - SLAB can capture huge amounts of memory in its queues. The problem gets worse the more processors and NUMA nodes are in the system. - SLAB requires a pass through all slab caches every 2 seconds to expire objects. This is a problem both for realtime and MPI jobs that cannot take such a processor outage. - SLAB does not have a sophisticated slabinfo tool to report the state of slab objects on the system. Can provide details of object use. - SLAB requires the update of two words for freeing and allocation. SLUB can do that by updating a single word which allows to avoid enabling and disabling interrupts if the processor supports an atomic instruction for that purpose. This is important for realtime kernels where special measures may have to be implemented. - SLAB requires memory to be set aside for queues (processors times number of slabs times queue size). SLUB requires none of that. - SLUB merges slab caches with similar characteristics to reduce the memory footprint even further. - SLAB performs object level NUMA management which creates a complex allocator complexity. SLUB manages NUMA on the level of slab pages. - SLUB allows remote node defragmentation to avoid the buildup of large partial lists on a single node. - SLUB can actively reduce the fragmentation of slabs through slab cache specific callbacks (not merged yet) - SLUB has resiliency features that allow it to isolate a problem object and continue after diagnostics have been performed. - SLUB creates rarely used DMA caches on demand instead of creating them all on bootup (SLAB). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-git7: Reported regressions from 2.6.23
On Friday, 21 of December 2007, Johannes Weiner wrote: > Hi, > > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > > > This message contains a list of some regressions from 2.6.23 reported since > > 2.6.24-rc1 was released, for which there are no fixes in the mainline I know > > of. If any of them have been fixed already, please let me know. > > > > If you know of any other unresolved regressions from 2.6.23, please let me > > know > > either and I'll add them to the list. Also, please let me know if any of > > the > > entries below are invalid. > > I still have a bug with cpufreq when using ondemand governor as default. Added as http://bugzilla.kernel.org/show_bug.cgi?id=9615 . Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Allow Kconfig to set default mmap_min_addr protection
On Dec 21 2007 22:16, Willy Tarreau wrote: >Hi Jan, > >> >> >+config SECURITY_DEFAULT_MMAP_MIN_ADDR >> >> >+int "Low address space to protect from user allocation" >> >> >> >> Hm, should not this be 'hex'? >> > >> >I guess it could be, but the input for /proc/sys/vm/mmap_min_addr is >> >base 10 as well >> >> sysfs is autobase, i.e. echo "0xb000" >/sys/foo will Do The Right Thing. > >yes but if you cat /proc/sys/vm/mmap_min_addr, it returns in base 10. sysfs should probably be tuned to output it in a preferred base. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: list corruption on ib_srp load in v2.6.24-rc5
On Fri, 2007-12-21 at 16:52 -0500, David Dillow wrote: > Before I get too far into this, has anyone seen this one before? I > looked at 'git diff v2.6.24-rc4..' and didn't see any changes that would > stand out as fixing it. This should read v2.6.24-rc5... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
list corruption on ib_srp load in v2.6.24-rc5
I'm getting the following oops when doing the following commands: modprobe ib_srp rmmod ib_srp modprobe ib_srp I'm going to try and track down how the list is getting corrupted; it looks like attribute_container_list in drivers/base/attribute_container.c is the one getting corrupted. Before I get too far into this, has anyone seen this one before? I looked at 'git diff v2.6.24-rc4..' and didn't see any changes that would stand out as fixing it. list_add corruption. prev->next should be next (81423ad0), but was . (prev=8108464cddd8). [ cut here ] kernel BUG at lib/list_debug.c:33! invalid opcode: [1] SMP CPU 3 Modules linked in: ib_srp sg sd_mod ib_iser libiscsi scsi_transport_iscsi rdma_ucm ib_ucm rdma_cm iw_cm ib_addr scsi_transport_srp scsi_mod ib_cm ib_ipoib ib_sa ib_uverbs ib_umad ib_mthca ib_mad ib_core ehci_hcd ohci_hcd nfs lockd nfs_acl sunrpc unionfs forcedeth Pid: 3640, comm: modprobe Not tainted 2.6.24-rc5 #2 RIP: 0010:[] [] __list_add+0x42/0x56 RSP: 0018:810844077f18 EFLAGS: 00010292 RAX: 0079 RBX: 810846619000 RCX: 812b7308 RDX: 812b7308 RSI: 0046 RDI: 812b7300 RBP: 881432c0 R08: 812b72f0 R09: R10: 0001 R11: R12: 2b54c0f72010 R13: R14: 006180c8 R15: 2b54c0f72010 FS: 2b54c14bb6e0() GS:810846531840() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 2b54c0fcd00f CR3: 000843ddc000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 3640, threadinfo 810844076000, task 8108402444c0) Stack: 8115170f 810846619000 88138448 88142080 0005b1cb 8809e00d 88142080 81056af1 Call Trace: [] attribute_container_register+0x44/0x54 [] :scsi_transport_srp:srp_attach_transport+0x74/0x115 [] :ib_srp:srp_init_module+0xd/0xc1 [] sys_init_module+0xad/0x14b [] system_call+0x7e/0x83 Code: 0f 0b eb fe 48 89 7e 08 48 89 37 48 89 47 08 48 89 38 59 c3 RIP [] __list_add+0x42/0x56 RSP # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc5 # Fri Dec 21 14:46:03 2007 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_QUICKLIST is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_SUPPORTS_OPROFILE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_FAIR_GROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_BLK_DEV_BSG=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y
Re: Major regression on hackbench with SLUB (more numbers)
On Fri, 21 Dec 2007, Ingo Molnar wrote: > > There are patches pending to address these issues. AFAICT Intel is > > testing if the regression is still there. There is no way for me to > > verify what is going on there and there is the constant difficulty of > > getting detailed information about what is going on at Intel. Every > > couple of month I get a result from that test. Its a really crappy > > situation where a lot of confusing information is passed around. > > of course there is a way to find out, and that's why i mailed you: fix > the hackbench regression and i'm quite sure you'll improve the TPC-C > numbers as well. It shows the same kind of overhead in the profile and > takes just a few seconds to run. Are your pending SLUB patches in > 2.6.24-rc5-mm1 already? The tests that I wrote emulate the test behavior that was described to me by me. The fixes in 2.6.24-rc5-mm1 improved those numbers. See http://lkml.org/lkml/2007/10/27/245 which I quoted earlier to you. However, I have no TPC-C setup here and from what I hear it takes weeks to run and requires a large support team for tuning. You can find the slab test suite for that at http://git.kernel.org/?p=linux/kernel/git/christoph/vm.git;a=shortlog;h=tests AFAICT the fixes in 2.6.25-rc5-mm1 result in double the alloc performance (fastpath) of SLAB. There are fixes that are not merged yet (the cpu alloc patchset) that seem to make that factor 3 because we can use the segment register to avoid per cpu array lookups in the fast path. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] PCI: use dev_printk in x86 quirk messages
On Tue, 18 Dec 2007 14:58:01 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Convert quirk printks to dev_printk(). > > thanks, applied the x86 bits. > Greg applied it too. Could you guys please sort out some sort of who-owns-what protocol? Thanks. > arch/x86/kernel/quirks.c | 42 ++ > arch/x86/pci/fixup.c | 22 +++--- That made it hard. Arguably one file is PCI tree and the other is x86 tree. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc5-mm1: problems with cat /proc/kpageflags
Hello, > > > [ 145.128915] TSTATE: 004411009603 TPC: 005119ac TNPC: > > > 005119b0 Y: Not tainted > > > [ 145.128940] TPC: > > > > My suspicion at this point is that with certain RAM layouts, simply > > iterating over PFN's is simply not working out. > > That was my original suspicion, which is why I asked Mariusz to > effectively comment out the actual PFN lookup up-thread. I didn't send > him a patch to do that, so I guess my instructions on how to hack it > may have been misunderstood. No. I just made a trivial mistake :-/ Sorry for confusion. I guess I need to verify things three times before sending an email next time. > > pfn_to_page() seems to be doing no range checking, and with sparsemem > > vmemmap, which sparc64 always uses, this can be problematic. > > > > It just blindly goes "vmemmap + pfn" which is asking for trouble, in > > particular when the physical RAM layout really is sparse. > > > > Maybe it's enough to add a pfn_valid() check here? If pfn_valid() > > means there is a vmemmap translation setup for that page struct too, > > it would work. > > Here's a test patch: Tested on 2.6.23 and 2.6.24-rc5-mm1. The patch fixes the bug. Thanks a lot to both of you. Mariusz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[announce] PS3 Linux Distributor's Starter Kit (v1.5.1) released
For those interested, an updated PS3 Linux Distributor's Starter Kit (v1.5.1) was released. This is a bug-fix release that only updates kboot and the linux kernel with the fix for the PS3 system update 2.10 frame buffer bug. The CD-ROM iso image is here (171 MiB): ftp://ftp.infradead.org/pub/Sony-PS3/CELL-Linux-CL_20071220-ADDON.iso http://ftp.uk.linux.org/pub/linux/Sony-PS3/CELL-Linux-CL_20071220-ADDON.iso I extracted files are here for convenient browsing: http://www.kernel.org/pub/linux/kernel/people/geoff/cell/CELL-Linux-CL_20071220-ADDON An updated kboot image is here: http://www.kernel.org/pub/linux/kernel/people/geoff/cell/kboot-20071220.bld More info on the 2.10 frame buffer bug is here: http://ozlabs.org/pipermail/cbe-oss-dev/2007-December/003727.html -Geoff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
