- 16 Dec, 2009 40 commits
-
-
Jack Steiner authored
Remove a stray local_irq_enable() in the GRU TLB dropin code. Signed-off-by:
Jack Steiner <steiner@sgi.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Jack Steiner authored
Use symbol names instead of numbers for error return values for the vtop functions. Signed-off-by:
-
Jack Steiner authored
Fix a GRU driver bug converting a CBR address to the context that contains the CBR. The conversion is rarely done so performance does not matter. Signed-off-by:
-
Jack Steiner authored
Add anticipatory TLB dropins for GRU TLB misses that occur on BCOPY instructions that copy large amounts of data. Signed-off-by:
-
Jack Steiner authored
Explicitly set GRU instructions to "ACTIVE". This eliminates the need for barriers that would have been necessary to prevent reading the instruction "status" field before the GRU had actually started the instruction. Signed-off-by:
-
Jack Steiner authored
Add additional GRU statistics & debug messages. Signed-off-by:
-
Jack Steiner authored
Update the GRU irq allocate/free functions to use the latest upstream infrastructure. Signed-off-by:
-
Jack Steiner authored
Fix several bugs related to prefetch, ordering & speculation: - GRU cch_allocate() instruction causes cacheable memory to be created. Add a barriers to prevent speculation from prefetching data before it exists. - Add memory barriers before cache-flush instructions to ensure that previously stored data is included in the line flushed to memory. Signed-off-by:
-
Jack Steiner authored
Fix bug caused by failure to allocate a GRU gts structure. The old code failed to handle the case where the vma was invalid. Signed-off-by:
-
Jack Steiner authored
Improve existing driver self-tests. Add a new debugging test to the SGI GRU driver for verifying the global GRU copy function. Signed-off-by:
-
Jack Steiner authored
Add a debug option to the SGI GRU driver for flushing GRU cache lines from memory. In theory this is not needed but it is useful for debugging. This has no use by end users. Signed-off-by:
-
Jack Steiner authored
Under some conditions, mmu_notifier_register() will fail to register a mmu_notifier. Fix the GRU driver to correctly handle these failures. Signed-off-by:
-
Jack Steiner authored
Increase the maximum address supported by the SGI GRU driver to a full 64 bits. Note that GRU addresses are not always the same as socket virtual addresses. Sockets may not necessarily support the full 64 bits. Signed-off-by:
-
Jack Steiner authored
Improve error messages for malfunctioning GRUs. Identify the type of instruction that is failing. Signed-off-by:
-
Jack Steiner authored
Fix bug in module unload. Previous code was not correctly deleting the files in /proc. Signed-off-by:
-
Jack Steiner authored
This patch builds on the infrastructure introduced in the patches that allow user specification of GRU blades & chiplets for context allocation. This patch simplifies the algorithms for migrating GRU contexts between blades. No new functionality is introduced. Signed-off-by:
-
Jack Steiner authored
Add support to the GRU driver to allow users to specify the blade & chiplet for allocation of GRU contexts. Add new statistics for context loading/unloading/retargeting. Also deleted a few GRU stats that were no longer being unused. Signed-off-by:
-
Jack Steiner authored
Add table & user request infrastructure that is needed to allow users to specify the blade and chiplet for allocation of GRU contexts. Use of this information is in a subsequent patch. Signed-off-by:
-
Jack Steiner authored
Do not use alloc_pages_exact_node() to allocate GRU tables. If a blade has no local memory, nid will be -1. Use alloc_pages_node() instead. Signed-off-by:
-
Jack Steiner authored
TLB dropins require updates to the CBR instruction istatus field. This is needed to resolve race conditions in the chip. The code currently uses the user address of the CBR. This works but opens up additional endcases related to stealing of contexts and accessing the CBR from tasks that do not have access to the user address space. (Some of this non-user task access is debug code that is not currently being pushed to the community). User CBRs are also directly accessible using the kernel mapping of the CBR. Change the TLB dropin code to use the the kernel mapping of the CBR. Signed-off-by:
-
Jack Steiner authored
Add comments from previous code reviews. The comments help explain some of the more esoteric aspects of the driver. Move a free() to the other side of an unlock. Signed-off-by:
-
Jack Steiner authored
Change the GRU initialization code to initialize based on blade topology instead of node topology. The result is the same but blade-based initialization is cleaner. Signed-off-by:
-
Robin Holt authored
Currently, the UV xpc code is passing nid to the gru_create_message_queue instead of nasid as it expects. Signed-off-by:
Robin Holt <holt@sgi.com> Signed-off-by:
-
Robin Holt authored
This was a difficult bug to trip. XPC was in the middle of sending an acknowledgement for a received message. In xpc_received_payload_uv(): . ret = xpc_send_gru_msg(ch->sn.uv.cached_notify_gru_mq_desc, msg, sizeof(struct xpc_notify_mq_msghdr_uv)); if (ret != xpSuccess) XPC_DEACTIVATE_PARTITION(&xpc_partitions[ch->partid], ret); msg->hdr.msg_slot_number += ch->remote_nentries; at the point in xpc_send_gru_msg() where the hardware has dispatched the acknowledgement, the remote side is able to reuse the message structure and send a message with a different slot number. This problem is made worse by interrupts. The adjustment of msg_slot_number and the BUG_ON in xpc_handle_notify_mq_msg_uv() which verifies the msg_slot_number is consistent are only used for debug purposes. Since a fix for this that preserves the debug functionality would either have to infringe upon the payload or allocate another structure just for debug, I decided to remove it entirely. Signed-off-by: -
Robin Holt authored
Many times while the initial connection is being made, the contacted partition will send back both the ACTIVATING and the ACTIVE remote_act_state changes in very close succescion. The 1/4 second delay in the make first contact loop is large enough to nearly always miss the ACTIVATING state change. Since either state indicates the remote partition has acknowledged our state change, accept either. Signed-off-by:
-
Robin Holt authored
Under heavy load conditions, our set of xpc messages may become exhausted. The code handles this correctly with the exception of the management code which hits a NULL pointer dereference. Signed-off-by:
-
Robin Holt authored
The UV BIOS has moved the location of some of their pointers to the "partition reserved page" from memory into a uv hub MMR. The GRU does not support bcopy operations from MMR space so we need to special case the MMR addresses using VLOAD operations. Additionally, the BIOS call for registering a message queue watchlist has removed the 'blade' value and eliminated the structure that was being passed in. This is also reflected in this patch. Signed-off-by:
-
Robin Holt authored
The BIOS has decided to store a pointer to the partition reserved page in a scratch MMR. The GRU is only able to read an MMR using a vload instruction. The gru_read_gpa() function will implemented. Signed-off-by:
-
Robin Holt authored
Provide a mechanism for determining if a global physical address is pointing to a UV hub MMR. Signed-off-by:
-
Robin Holt authored
Provide an SGI SN2/UV agnositic method for converting a global physical address into a socket physical address. Signed-off-by:
-
Robin Holt authored
The UV BIOS has been updated to implement some of our interface functionality differently than originally expected. These patches update the kernel to the bios implementation and include a few minor bug fixes which prevent us from doing significant testing on real hardware. This patch: For SGI UV systems, translate from a global physical address back to a socket physical address. This does nothing to ensure the socket physical address is actually addressable by the kernel. That is the responsibility of the user of the function. Signed-off-by:
-
Christoph Hellwig authored
Currently the locking in blockdev_direct_IO is a mess, we have three different locking types and very confusing checks for some of them. The most complicated one is DIO_OWN_LOCKING for reads, which happens to not actually be used. This patch gets rid of the DIO_OWN_LOCKING - as mentioned above the read case is unused anyway, and the write side is almost identical to DIO_NO_LOCKING. The difference is that DIO_NO_LOCKING always sets the create argument for the get_blocks callback to zero, but we can easily move that to the actual get_blocks callbacks. There are four users of the DIO_NO_LOCKING mode: gfs already ignores the create argument and thus is fine with the new version, ocfs2 only errors out if create were ever set, and we can remove this dead code now, the block device code only ever uses create for an error message if we are fully beyond the device which can never happen, and last but not least XFS will need the new behavour for writes. Now we can replace the lock_type variable with a flags one, where no flag means the DIO_NO_LOCKING behaviour and DIO_LOCKING is kept as the first flag. Separate out the check for not allowing to fill holes into a separate flag, although for now both flags always get set at the same time. Also revamp the documentation of the locking scheme to actually make sense. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Christoph Hellwig <hch@lst.de> Cc: Dave Chinner <david@fromorbit.com> Cc: Badari Pulavarty <pbadari@us.ibm.com> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Jens Axboe <jens.axboe@oracle.com> Cc: Zach Brown <zach.brown@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Alex Elder <aelder@sgi.com> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <joel.becker@oracle.com> Signed-off-by:
-
Jeff Moyer authored
Intel reported a performance regression caused by the following commit: commit 848c4dd5 Author: Zach Brown <zach.brown@oracle.com> Date: Mon Aug 20 17:12:01 2007 -0700 dio: zero struct dio with kzalloc instead of manually This patch uses kzalloc to zero all of struct dio rather than manually trying to track which fields we rely on being zero. It passed aio+dio stress testing and some bug regression testing on ext3. This patch was introduced by Linus in the conversation that lead up to Badari's minimal fix to manually zero .map_bh.b_state in commit: 6a648fa7 It makes the code a bit smaller. Maybe a couple fewer cachelines to load, if we're lucky: text data bss dec hex filename 3285925 568506 1304616 5159047 4eb887 vmlinux 3285797 568506 1304616 5158919 4eb807 vmlinux.patched I was unable to measure a stable difference in the number of cpu cycles spent in blockdev_direct_IO() when pushing aio+dio 256K reads at ~340MB/s. So the resulting intent of the patch isn't a performance gain but to avoid exposing ourselves to the risk of finding another field like .map_bh.b_state where we rely on zeroing but don't enforce it in the code. Zach surmised that zeroing out the page array was what caused most of the problem, and suggested the approach taken in the attached patch for resolving the issue. Intel re-tested with this patch and saw a 0.6% performance gain (the original regression was 0.5%). [akpm@linux-foundation.org: add comment] Signed-off-by:
Jeff Moyer <jmoyer@redhat.com> Acked-by:
Zach Brown <zach.brown@oracle.com> Signed-off-by:
-
Shaohua Li authored
Don't know the reason, but it appears ki_wait field of iocb never gets used. Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Cc: Jeff Moyer <jmoyer@redhat.com> Cc: Benjamin LaHaise <bcrl@kvack.org> Cc: Zach Brown <zach.brown@oracle.com> Signed-off-by:
-
David Howells authored
Andrew Morton's compiler sees the following warning in FS-Cache: fs/fscache/object-list.c: In function 'fscache_objlist_lookup': fs/fscache/object-list.c:94: warning: 'obj' may be used uninitialized in this function which my compiler doesn't. This is a false positive as obj can only be used in the comparison against minobj if minobj has been set to something other than NULL, but for that to happen, obj has to be first set to something. Deal with this by preclearing obj too. Reported-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Amerigo Wang authored
Implement shrinking the reserved memory for crash kernel, if it is more than enough. For example, if you have already reserved 128M, now you just want 100M, you can do: # echo $((100*1024*1024)) > /sys/kernel/kexec_crash_size Note, you can only do this before loading the crash kernel. Signed-off-by:
WANG Cong <amwang@redhat.com> Cc: Neil Horman <nhorman@redhat.com> Acked-by:
Eric W. Biederman <ebiederm@xmission.com> Cc: Andi Kleen <andi@firstfloor.org> Signed-off-by:
-
Joe Perches authored
Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Jan Beulich authored
dma_mask is, when interpreted as address, the last valid byte, and hence comparison msut also be done using the last valid of the buffer in question. Also fix the open-coded instances in lib/swiotlb.c. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Becky Bruce <beckyb@kernel.crashing.org> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
Nils Carlson authored
Add support for 6 ranks per channel to the i5100 chipset. I have tested the patch as far as possible with correctible errors and things appear good. The DIMM mapping is correct for our board, but boards may differ. Signed-off-by:
Nils Carlson <nils.carlson@ludd.ltu.se> Acked-by:
Arthur Jones <ajones@riverbed.com> Signed-off-by:
Doug Thompson <dougthompson@xmission.com> Signed-off-by:
-
Nils Carlson authored
Addscrubbing to the i5100 chipset. The i5100 chipset only supports one scrubbing rate, which is not constant but dependent on memory load. The rate returned by this driver is an estimate based on some experimentation, but is substantially closer to the truth than the speed supplied in the documentation. Also, scrubbing is done once, and then a done-bit is set. This means that to accomplish continuous scrubbing a re-enabling mechanism must be used. I have created the simplest possible such mechanism in the form of a work-queue which will check every five minutes. This interval is quite arbitrary but should be sufficient for all sizes of system memory. Signed-off-by:
-
