aboutsummaryrefslogtreecommitdiff
path: root/arch/x86/include/asm/uv
AgeCommit message (Collapse)AuthorFilesLines
2017-03-13x86/platform/uv/BAU: Add wait_completion to bau_operationsAndrew Banman1-0/+2
Remove the present wait_completion routine and add a function pointer by the same name to the bau_operations struct. Rather than switching on the UV hub version during message processing, set the architecture-specific uv*_wait_completion during initialization. The uv123_bau_ops struct must be split into uv1 and uv2_3 versions to accommodate the corresponding wait_completion routines. Signed-off-by: Andrew Banman <[email protected]> Acked-by: Ingo Molnar <[email protected]> Acked-by: Mike Travis <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-03-13x86/platform/uv/BAU: Add status mmr location fields to bau_controlAndrew Banman1-2/+8
The location of the ERROR and BUSY status bits depends on the descriptor index, i.e. the CPU, of the message. Since this index does not change, there is no need to calculate the mmr and index location during message processing. The less work we do in the hot path the better. Add status_mmr and status_index fields to bau_control and compute their values during initialization. Add kerneldoc descriptions for the new fields. Update uv*_wait_completion to use these fields rather than receiving the information as parameters. Signed-off-by: Andrew Banman <[email protected]> Acked-by: Ingo Molnar <[email protected]> Acked-by: Mike Travis <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-03-13x86/platform/uv/BAU: Cleanup bau_operations declaration and instancesAndrew Banman1-11/+11
Move the bau_operations declaration after bau struct declarations so the bau structs can be referenced when adding new functions to bau_operations. That way we avoid forward declarations of the bau structs. Likewise, move uv*_bau_ops structs down to avoid forward declarations of new functions defined in the same file. Declare these structs __initconst since they are only used during initialization. Similarly, declare the bau_operations ops instance __ro_after_init as it is read-only after initialization. This is a preparatory patch for adding wait_completion to bau_operations. Signed-off-by: Andrew Banman <[email protected]> Acked-by: Ingo Molnar <[email protected]> Acked-by: Mike Travis <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-03-13x86/platform/uv/BAU: Add payload descriptor qualifierAndrew Banman1-12/+29
On UV4, the destination agent verifies each message by checking the descriptor qualifier field of the message payload. Messages without this field set to 0x534749 will cause a hub error to assert. Split bau_message_payload into uv1_2_3 and uv4 versions to account for the different payload formats. Enforce the size of each field by using the appropriate u** integer type. Replace extraneous comments with KernelDoc comment. Signed-off-by: Andrew Banman <[email protected]> Acked-by: Ingo Molnar <[email protected]> Acked-by: Mike Travis <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-03-13x86/platform/uv/BAU: Add uv_bau_version enumerated constantsAndrew Banman1-0/+7
Define enumerated constants for each UV hub version and replace magic numbers with the appropriate constant. Signed-off-by: Andrew Banman <[email protected]> Acked-by: Ingo Molnar <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2017-02-01x86/platform/UV: Add Support for UV4 Hubless NMIs[email protected]1-0/+3
Merge new UV Hubless NMI support into existing UV NMI handler. Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Russ Anderson <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: Dimitri Sivanich <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2017-02-01x86/platform/UV: Add Support for UV4 Hubless systems[email protected]1-0/+2
Add recognition and support for UV4 hubless systems. Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Russ Anderson <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: Dimitri Sivanich <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-09-22x86/platform/uv/BAU: Add UV4-specific functionsAndrew Banman1-0/+30
Add the UV4-specific function definitions and define an operations struct to implement them in the BAU driver. Many BAU MMRs, although functionally the same, have new addresses on UV4 due to hardware changes. Each MMR requires new read/write functions, but their implementation in the driver does not change. Thus, it is enough to enumerate them in the operations struct for the changes to take effect. Signed-off-by: Andrew Banman <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: Mike Travis <[email protected]> Acked-by: Dimitri Sivanich <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-09-22x86/platform/uv/BAU: Add generic function pointersAndrew Banman1-0/+11
Many BAU functions have different implementations depending on the UV version. Rather than switching on the uvhub_version throughout the driver, we can define a set of operations for each version. This is especially beneficial for UV4, which will require many new MMR read/write functions. Currently, the set of abstracted functions are the same for UV1, UV2, and UV3. The functions were chosen because each one will have a different implementation for UV4. Other functions will be added as needed to handle new implementations or to cleanup the existing differences between UV1, UV2, and UV3, i.e. read_status and wait_completion. Signed-off-by: Andrew Banman <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: Mike Travis <[email protected]> Acked-by: Dimitri Sivanich <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-09-22x86/platform/uv/BAU: Convert uv_physnodeaddr() use to uv_gpa_to_offset()Andrew Banman1-2/+0
The BAU driver should use the functions provided by uv_hub.h rather than its own implementations. uv_physnodeaddr converts vaddrs to paddrs for BAU MMR fields, but this is done better by uv_gpa_to_offset. Signed-off-by: Andrew Banman <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: Mike Travis <[email protected]> Acked-by: Dimitri Sivanich <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-09-22x86/platform/uv/BAU: Clean up pq_init()Andrew Banman1-1/+1
The payload queue first MMR requires the physical memory address and hub GNODE of where the payload queue resides in memory, but the associated variables are named as if the PNODE were used. Rename gnode-related variables and clarify the definitions of the payload queue head, last, and tail pointers. Signed-off-by: Andrew Banman <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Acked-by: Mike Travis <[email protected]> Acked-by: Dimitri Sivanich <[email protected]> Acked-by: Thomas Gleixner <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: [email protected] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-08-10x86/platform/UV: Fix problem with UV4 BIOS providing incorrect PXM valuesMike Travis1-2/+3
There are some circumstances where the UV4 BIOS cannot provide the correct Proximity Node values to associate with specific Sockets and Physical Nodes. The decision was made to remove these values from BIOS and for the kernel to get these values from the standard ACPI tables. Tested-by: Frank Ramsay <[email protected]> Tested-by: John Estabrook <[email protected]> Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Reviewed-by: Nathan Zimmer <[email protected]> Cc: Alex Thorlton <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Remove Obsolete GRU MMR address translationDimitri Sivanich1-10/+0
Use no-op messages in place of cross-partition interrupts when nacking a put message in the GRU. This allows us to remove MMR's as a destination from the GRU driver. Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Dimitri Sivanich <[email protected]> Signed-off-by: Mike Travis <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Update physical address conversions for UV4Mike Travis1-17/+114
This patch builds support for the new conversions of physical addresses to and from sockets, pnodes and nodes in UV4. It is designed to be as efficient as possible as lookups are done inside an interrupt context in some cases. It will be further optimized when physical hardware is available to measure execution time. Tested-by: Dimitri Sivanich <[email protected]> Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Build GAM reference tablesMike Travis1-2/+16
An aspect of the UV4 system architecture changes involve changing the way sockets, nodes, and pnodes are translated between one another. Decode the information from the BIOS provided EFI system table to build the needed conversion tables. Tested-by: Dimitri Sivanich <[email protected]> Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Support UV4 socket address changesMike Travis1-2/+9
With the UV4 system architecture addressing changes, BIOS now provides this information via an EFI system table. This is the initial decoding of that system table. It also collects the sizing information for later allocation of dynamic conversion tables. Tested-by: Dimitri Sivanich <[email protected]> Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Add obtaining GAM Range Table from UV BIOSMike Travis1-2/+57
UV4 uses a GAM (globally addressed memory) architecture that supports variable sized memory per node. This replaces the old "M" value (number of address bits per node) with a range table for conversions between addresses and physical node (pnode) id's. This table is obtained from UV BIOS via the EFI UVsystab table. Support for older EFI UVsystab tables is maintained. Tested-by: Dimitri Sivanich <[email protected]> Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Fold blade info into per node hub info structsMike Travis1-39/+32
Migrate references from the blade info structs to the per node hub info structs. This phases out the allocation of the list of per blade info structs on node 0, in favor of a per node hub info struct allocated on the node's local memory. There are also some minor cosemetic changes in the comments and whitespace to clean things up a bit. Tested-by: Dimitri Sivanich <[email protected]> Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Allocate common per node hub info structs on local nodeMike Travis1-4/+32
Allocate and setup per node hub info structs. CPU 0/Node 0 hub info is statically allocated to be accessible early in system startup. The remaining hub info structs are allocated on the node's local memory, and shared among the CPU's on that node. This leaves the small amount of info unique to each CPU in the per CPU info struct. Memory is saved by combining the common per node info fields to common node local structs. In addtion, since the info is read only only after setup, it should stay in the L3 cache of the local processor socket. This should therefore improve the cache hit rate when a group of cpus on a node are all interrupted for a common task. Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Reviewed-by: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Move blade local processor ID to the per cpu info structMike Travis1-2/+8
Move references to blade local processor ID to the new per cpu info structs. Create an access function that makes this move, and other potential moves opaque to callers of this function. Define a flag that indicates to callers in external GPL modules that this function replaces any local definition. This allows calling source code to be built for both pre-UV4 kernels as well as post-UV4 kernels. Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Move scir info to the per cpu info structMike Travis1-7/+10
Change the references to the SCIR fields to the new per cpu info structs. Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Create per cpu info structs to replace per hub info structsMike Travis1-4/+15
The major portion of the hub info is common to all cpus on that hub. This is step one of moving the per cpu hub info to a per node hub info struct. This patch creates the small per cpu info struct that will contain only information specific to each CPU. Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Clean up redunduncies after merge of UV4 MMR definitionsMike Travis1-9/+0
Clean up any redundancies caused by new UV4 MMR definitions superseding any previously definitions local to functions. Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Reviewed-by: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Add UV4 Specific MMR definitionsMike Travis1-422/+1769
This adds the MMR definitions for UV4 via an automated script that uses the output from a hardware verilog code to symbol converter. The large number of insertions is caused by the UV4 design changing many similarly named fields in MMR's that are named the same. This prompted the extra production of architecture dependent field defines. Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: Dimitri Sivanich <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Prep for UV4 MMR updatesMike Travis1-0/+5
Cleanup patch to rearrange code and modify some defines so the next patch, the new UV4 MMR definitions can be merged cleanly. * Clean up the M/N related address constants (M is # of address bits per blade, N is the # of blade selection bits per SSI/partition). * Fix the lookup of the alias overlay addresses and NMI definitions to allow for flexibility in newer UV architecture types. Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Add UV Architecture DefinesMike Travis1-5/+31
Add defines to control which UV architectures are supported, and modify the 'if (is_uvX_*)' functions to return constant 0 for those not supported. This will help optimize code paths when support for specific UV arches is removed. Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-05-04x86/platform/UV: Add Initial UV4 definitionsMike Travis2-24/+62
Add preliminary UV4 defines. Tested-by: John Estabrook <[email protected]> Tested-by: Gary Kroening <[email protected]> Tested-by: Nathan Zimmer <[email protected]> Signed-off-by: Mike Travis <[email protected]> Cc: Andrew Banman <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: Dimitri Sivanich <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Len Brown <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-04-01x86/platform/uv: Disable UV BAU by defaultAlex Thorlton1-1/+1
For several years, the common practice has been to boot UVs with the "nobau" parameter on the command line, to disable the BAU. We've decided that it makes more sense to just disable the BAU by default in the kernel, and provide the option to turn it on, if desired. For now, having the on/off switch doesn't buy us any more than just reversing the logic would, but we're working towards having the BAU enabled by default on UV4. When those changes are in place, having the on/off switch will make more sense than an enable flag, since the default behavior will be different depending on the system version. I've also added a bit of documentation for the new parameter to Documentation/kernel-parameters.txt. Signed-off-by: Alex Thorlton <[email protected]> Reviewed-by: Hedi Berriche <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-09-13x86/platform/uv: Insert per_cpu accessor function on uv_hub_nmiGeorge Beshers1-1/+1
UV: NMI: insert this_cpu_read accessor function on uv_hub_nmi. On SGI UV systems a 'power nmi' command from the CMC causes all processors to drop into uv_handle_nmi(). With the 4.0 kernel this results in BUG: unable to handle kernel paging request The bug is caused by the current code trying to use the PER_CPU variable uv_cpu_nmi.hub without an appropriate accessor function. That oversight occurred in commit e16321709c82 ("uv: Replace __get_cpu_var") Author: Christoph Lameter <[email protected]> Date: Sun Aug 17 12:30:41 2014 -0500 This patch inserts this_cpu_read() in the uv_hub_nmi macro restoring the intended functionality. Signed-off-by: George Beshers <[email protected]> Acked-by: Mike Travis <[email protected]> Cc: Alex Thorlton <[email protected]> Cc: Dimitri Sivanich <[email protected]> Cc: Hedi Berriche <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Signed-off-by: Ingo Molnar <[email protected]>
2014-11-03x86: UV BAU: Increase maximum CPUs per socket/hubJames Custer1-2/+2
We have encountered hardware with 18 cores/socket that gives 36 CPUs/socket with hyperthreading enabled. This exceeds the current MAX_CPUS_PER_SOCKET causing a failure in get_cpu_topology. Increase MAX_CPUS_PER_SOCKET to 64 and MAX_CPUS_PER_UVHUB to 128. Signed-off-by: James Custer <[email protected]> Cc: Russ Anderson <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2014-08-26uv: Replace __get_cpu_varChristoph Lameter1-5/+5
Use __this_cpu_read instead. Cc: Hedi Berriche <[email protected]> Cc: Mike Travis <[email protected]> Cc: Dimitri Sivanich <[email protected]> Signed-off-by: Christoph Lameter <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2014-08-26x86: Replace __get_cpu_var usesChristoph Lameter1-1/+1
__get_cpu_var() is used for multiple purposes in the kernel source. One of them is address calculation via the form &__get_cpu_var(x). This calculates the address for the instance of the percpu variable of the current processor based on an offset. Other use cases are for storing and retrieving data from the current processors percpu area. __get_cpu_var() can be used as an lvalue when writing data or on the right side of an assignment. __get_cpu_var() is defined as : #define __get_cpu_var(var) (*this_cpu_ptr(&(var))) __get_cpu_var() always only does an address determination. However, store and retrieve operations could use a segment prefix (or global register on other platforms) to avoid the address calculation. this_cpu_write() and this_cpu_read() can directly take an offset into a percpu area and use optimized assembly code to read and write per cpu variables. This patch converts __get_cpu_var into either an explicit address calculation using this_cpu_ptr() or into a use of this_cpu operations that use the offset. Thereby address calculations are avoided and less registers are used when code is generated. Transformations done to __get_cpu_var() 1. Determine the address of the percpu instance of the current processor. DEFINE_PER_CPU(int, y); int *x = &__get_cpu_var(y); Converts to int *x = this_cpu_ptr(&y); 2. Same as #1 but this time an array structure is involved. DEFINE_PER_CPU(int, y[20]); int *x = __get_cpu_var(y); Converts to int *x = this_cpu_ptr(y); 3. Retrieve the content of the current processors instance of a per cpu variable. DEFINE_PER_CPU(int, y); int x = __get_cpu_var(y) Converts to int x = __this_cpu_read(y); 4. Retrieve the content of a percpu struct DEFINE_PER_CPU(struct mystruct, y); struct mystruct x = __get_cpu_var(y); Converts to memcpy(&x, this_cpu_ptr(&y), sizeof(x)); 5. Assignment to a per cpu variable DEFINE_PER_CPU(int, y) __get_cpu_var(y) = x; Converts to __this_cpu_write(y, x); 6. Increment/Decrement etc of a per cpu variable DEFINE_PER_CPU(int, y); __get_cpu_var(y)++ Converts to __this_cpu_inc(y) Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Acked-by: H. Peter Anvin <[email protected]> Acked-by: Ingo Molnar <[email protected]> Signed-off-by: Christoph Lameter <[email protected]> Signed-off-by: Tejun Heo <[email protected]>
2014-06-05x86/uv: Update the UV3 TLB shootdown logicCliff Wickman1-8/+11
Update of TLB shootdown code for UV3. Kernel function native_flush_tlb_others() calls uv_flush_tlb_others() on UV to invalidate tlb page definitions on remote cpus. The UV systems have a hardware 'broadcast assist unit' which can be used to broadcast shootdown messages to all cpu's of selected nodes. The behavior of the BAU has changed only slightly with UV3: - UV3 is recognized with is_uv3_hub(). - UV2 functions and structures (uv2_xxx) are in most cases simply renamed to uv2_3_xxx. - Some UV2 error workarounds are not needed for UV3. (see uv_bau_message_interrupt and enable_timeouts) Signed-off-by: Cliff Wickman <[email protected]> Link: http://lkml.kernel.org/r/[email protected] [ Removed a few linebreak uglies. ] Signed-off-by: Ingo Molnar <[email protected]>
2014-04-01x86/UV: Set n_lshift based on GAM_GR_CONFIG MMR for UV3Dimitri Sivanich2-12/+42
The value of n_lshift for UV is currently set based on the socket m_val. For UV3, set the n_lshift value based on the GAM_GR_CONFIG MMR. This will allow bios to control the n_lshift value independent of the socket m_val. Then n_lshift can be assigned a fixed value across a multi-partition system, allowing for a fixed common global physical address format that is independent of socket m_val. Cleanup unneeded macros. Signed-off-by: Dimitri Sivanich <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2014-01-25x86/uv/nmi: Fix Sparse warningsMike Travis1-2/+0
Make uv_register_nmi_notifier() and uv_handle_nmi_ping() static to address sparse warnings. Fix problem where uv_nmi_kexec_failed is unused when CONFIG_KEXEC is not defined. Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Hedi Berriche <[email protected]> Cc: Russ Anderson <[email protected]> Cc: Jason Wessel <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-11-11Revert "x86/UV: Add uvtrace support"Ingo Molnar1-8/+0
This reverts commit 8eba18428ac926f436064ac281e76d36d51bd631. uv_trace() is not used by anything, nor is uv_trace_nmi_func, nor uv_trace_func. That's not how we do instrumentation code in the kernel: we add tracepoints, printk()s, etc. so that everyone not just those with magic kernel modules can debug a system. So remove this unused (and misguied) piece of code. Signed-off-by: Ingo Molnar <[email protected]> Cc: Mike Travis <[email protected]> Cc: Dimitri Sivanich <[email protected]> Cc: Hedi Berriche <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jason Wessel <[email protected]> Link: http://lkml.kernel.org/n/[email protected]
2013-09-24x86/UV: Add uvtrace supportMike Travis1-0/+8
This patch adds support for the uvtrace module by providing a skeleton call to the registered trace function. It also provides another separate 'NMI' tracer that is triggered by the system wide 'power nmi' command. Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Reviewed-by: Hedi Berriche <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jason Wessel <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-09-24x86/UV: Update UV support for external NMI signalsMike Travis2-2/+86
The current UV NMI handler has not been updated for the changes in the system NMI handler and the perf operations. The UV NMI handler reads an MMR in the UV Hub to check to see if the NMI event was caused by the external 'system NMI' that the operator can initiate on the System Mgmt Controller. The problem arises when the perf tools are running, causing millions of perf events per second on very large CPU count systems. Previously this was okay because the perf NMI handler ran at a higher priority on the NMI call chain and if the NMI was a perf event, it would stop calling other NMI handlers remaining on the NMI call chain. Now the system NMI handler calls all the handlers on the NMI call chain including the UV NMI handler. This causes the UV NMI handler to read the MMRs at the same millions per second rate. This can lead to significant performance loss and possible system failures. It also can cause thousands of 'Dazed and Confused' messages being sent to the system console. This effectively makes perf tools unusable on UV systems. To avoid this excessive overhead when perf tools are running, this code has been optimized to minimize reading of the MMRs as much as possible, by moving to the NMI_UNKNOWN notifier chain. This chain is called only when all the users on the standard NMI_LOCAL call chain have been called and none of them have claimed this NMI. There is an exception where the NMI_LOCAL notifier chain is used. When the perf tools are in use, it's possible that the UV NMI was captured by some other NMI handler and then either ignored or mistakenly processed as a perf event. We set a per_cpu ('ping') flag for those CPUs that ignored the initial NMI, and then send them an IPI NMI signal. The NMI_LOCAL handler on each cpu does not need to read the MMR, but instead checks the in memory flag indicating it was pinged. There are two module variables, 'ping_count' indicating how many requested NMI events occurred, and 'ping_misses' indicating how many stray NMI events. These most likely are perf events so it shows the overhead of the perf NMI interrupts and how many MMR reads were avoided. This patch also minimizes the reads of the MMRs by having the first cpu entering the NMI handler on each node set a per HUB in-memory atomic value. (Having a per HUB value avoids sending lock traffic over NumaLink.) Both types of UV NMIs from the SMI layer are supported. Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Reviewed-by: Hedi Berriche <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jason Wessel <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-09-24x86/UV: Move NMI supportMike Travis1-0/+2
This patch moves the UV NMI support from the x2apic file to a new separate uv_nmi.c file in preparation for the next sequence of patches. It prevents upcoming bloat of the x2apic file, and has the added benefit of putting the upcoming /sys/module parameters under the name 'uv_nmi' instead of 'x2apic_uv_x', which was obscure. Signed-off-by: Mike Travis <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Reviewed-by: Hedi Berriche <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Jason Wessel <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-06-20x86, trace: Add irq vector tracepointsSeiji Aguchi1-0/+3
[Purpose of this patch] As Vaibhav explained in the thread below, tracepoints for irq vectors are useful. http://www.spinics.net/lists/mm-commits/msg85707.html <snip> The current interrupt traces from irq_handler_entry and irq_handler_exit provide when an interrupt is handled. They provide good data about when the system has switched to kernel space and how it affects the currently running processes. There are some IRQ vectors which trigger the system into kernel space, which are not handled in generic IRQ handlers. Tracing such events gives us the information about IRQ interaction with other system events. The trace also tells where the system is spending its time. We want to know which cores are handling interrupts and how they are affecting other processes in the system. Also, the trace provides information about when the cores are idle and which interrupts are changing that state. <snip> On the other hand, my usecase is tracing just local timer event and getting a value of instruction pointer. I suggested to add an argument local timer event to get instruction pointer before. But there is another way to get it with external module like systemtap. So, I don't need to add any argument to irq vector tracepoints now. [Patch Description] Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all events. But there is an above use case to trace specific irq_vector rather than tracing all events. In this case, we are concerned about overhead due to unwanted events. So, add following tracepoints instead of introducing irq_vector_entry/exit. so that we can enable them independently. - local_timer_vector - reschedule_vector - call_function_vector - call_function_single_vector - irq_work_entry_vector - error_apic_vector - thermal_apic_vector - threshold_apic_vector - spurious_apic_vector - x86_platform_ipi_vector Also, introduce a logic switching IDT at enabling/disabling time so that a time penalty makes a zero when tracepoints are disabled. Detailed explanations are as follows. - Create trace irq handlers with entering_irq()/exiting_irq(). - Create a new IDT, trace_idt_table, at boot time by adding a logic to _set_gate(). It is just a copy of original idt table. - Register the new handlers for tracpoints to the new IDT by introducing macros to alloc_intr_gate() called at registering time of irq_vector handlers. - Add checking, whether irq vector tracing is on/off, into load_current_idt(). This has to be done below debug checking for these reasons. - Switching to debug IDT may be kicked while tracing is enabled. - On the other hands, switching to trace IDT is kicked only when debugging is disabled. In addition, the new IDT is created only when CONFIG_TRACING is enabled to avoid being used for other purposes. Signed-off-by: Seiji Aguchi <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: H. Peter Anvin <[email protected]> Cc: Steven Rostedt <[email protected]>
2013-02-11x86, uv, uv3: Trim MMR register definitions after code changes for SGI UV3Mike Travis1-2479/+1
This patch trims the MMR register definitions after the updates for the SGI UV3 system have been applied. Note that because these definitions are automatically generated from the RTL we cannot control the length of the names. Therefore there are lines that exceed 80 characters. Signed-off-by: Mike Travis <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Acked-by: Russ Anderson <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]>
2013-02-11x86, uv, uv3: Update Hub Info for SGI UV3Mike Travis1-8/+36
This patch updates the UV HUB info for UV3. The "is_uv3_hub" and "is_uvx_hub" (UV2 or UV3) functions are added as well as the addresses and sizes of the MMR regions for UV3. Signed-off-by: Mike Travis <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Acked-by: Russ Anderson <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]>
2013-02-11x86, uv, uv3: Update MMR register definitions for SGI Ultraviolet System 3 (UV3)Mike Travis1-108/+3366
This patch updates the MMR register definitions for the SGI UV3 system. Note that because these definitions are automatically generated from the RTL we cannot control the length of the names. Therefore there are lines that exceed 80 characters. All the new MMR definitions are added in this patch. The patches that follow then update the references. The last patch is a "trim" patch which reduces the size of the MMR definitions file by about a third. This keeps "bi-sectability" in place as the intermediate patches would not compile correctly if the trimmed MMR defines were done first. Signed-off-by: Mike Travis <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Acked-by: Russ Anderson <[email protected]> Reviewed-by: Dimitri Sivanich <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]>
2013-01-24arch/x86/platform/uv: Fix incorrect tlb flush all issueAlex Shi1-1/+1
The flush tlb optimization code has logical issue on UV platform. It doesn't flush the full range at all, since it simply ignores its 'end' parameter (and hence also the "all" indicator) in uv_flush_tlb_others() function. Cliff's notes: | I tested the patch on a UV. It has the effect of either | clearing 1 or all TLBs in a cpu. I added some debugging to | test for the cases when clearing all TLBs is overkill, and in | practice it happens very seldom. Reported-by: Jan Beulich <[email protected]> Signed-off-by: Alex Shi <[email protected]> Signed-off-by: Cliff Wickman <[email protected]> Tested-by: Cliff Wickman <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2012-07-26Merge branch 'x86-mm-for-linus' of ↵Linus Torvalds1-2/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86/mm changes from Peter Anvin: "The big change here is the patchset by Alex Shi to use INVLPG to flush only the affected pages when we only need to flush a small page range. It also removes the special INVALIDATE_TLB_VECTOR interrupts (32 vectors!) and replace it with an ordinary IPI function call." Fix up trivial conflicts in arch/x86/include/asm/apic.h (added code next to changed line) * 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/tlb: Fix build warning and crash when building for !SMP x86/tlb: do flush_tlb_kernel_range by 'invlpg' x86/tlb: replace INVALIDATE_TLB_VECTOR by CALL_FUNCTION_VECTOR x86/tlb: enable tlb flush range support for x86 mm/mmu_gather: enable tlb flush range in generic mmu_gather x86/tlb: add tlb_flushall_shift knob into debugfs x86/tlb: add tlb_flushall_shift for specific CPU x86/tlb: fall back to flush all when meet a THP large page x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range x86/tlb_info: get last level TLB entry number of CPU x86: Add read_mostly declaration/definition to variables from smp.h x86: Define early read-mostly per-cpu macros
2012-06-27x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_rangeAlex Shi1-2/+3
x86 has no flush_tlb_range support in instruction level. Currently the flush_tlb_range just implemented by flushing all page table. That is not the best solution for all scenarios. In fact, if we just use 'invlpg' to flush few lines from TLB, we can get the performance gain from later remain TLB lines accessing. But the 'invlpg' instruction costs much of time. Its execution time can compete with cr3 rewriting, and even a bit more on SNB CPU. So, on a 512 4KB TLB entries CPU, the balance points is at: (512 - X) * 100ns(assumed TLB refill cost) = X(TLB flush entries) * 100ns(assumed invlpg cost) Here, X is 256, that is 1/2 of 512 entries. But with the mysterious CPU pre-fetcher and page miss handler Unit, the assumed TLB refill cost is far lower then 100ns in sequential access. And 2 HT siblings in one core makes the memory access more faster if they are accessing the same memory. So, in the patch, I just do the change when the target entries is less than 1/16 of whole active tlb entries. Actually, I have no data support for the percentage '1/16', so any suggestions are welcomed. As to hugetlb, guess due to smaller page table, and smaller active TLB entries, I didn't see benefit via my benchmark, so no optimizing now. My micro benchmark show in ideal scenarios, the performance improves 70 percent in reading. And in worst scenario, the reading/writing performance is similar with unpatched 3.4-rc4 kernel. Here is the reading data on my 2P * 4cores *HT NHM EP machine, with THP 'always': multi thread testing, '-t' paramter is thread number: with patch unpatched 3.4-rc4 ./mprotect -t 1 14ns 24ns ./mprotect -t 2 13ns 22ns ./mprotect -t 4 12ns 19ns ./mprotect -t 8 14ns 16ns ./mprotect -t 16 28ns 26ns ./mprotect -t 32 54ns 51ns ./mprotect -t 128 200ns 199ns Single process with sequencial flushing and memory accessing: with patch unpatched 3.4-rc4 ./mprotect 7ns 11ns ./mprotect -p 4096 -l 8 -n 10240 21ns 21ns [ hpa: http://lkml.kernel.org/r/1B4B44D9196EFF41AE41FDA404FC0A100BFF94@SHSMSX101.ccr.corp.intel.com has additional performance numbers. ] Signed-off-by: Alex Shi <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: H. Peter Anvin <[email protected]>
2012-06-25x86/uv: Work around UV2 BAU hangsCliff Wickman1-10/+18
On SGI's UV2 the BAU (Broadcast Assist Unit) driver can hang under a heavy load. To cure this: - Disable the UV2 extended status mode (see UV2_EXT_SHFT), as this mode changes BAU behavior in more ways then just delivering an extra bit of status. Revert status to just two meaningful bits, like UV1. - Use no IPI-style resets on UV2. Just give up the request for whatever the reason it failed and let it be accomplished with the legacy IPI method. - Use no alternate sending descriptor (the former UV2 workaround bcp->using_desc and handle_uv2_busy() stuff). Just disable the use of the BAU for a period of time in favor of the legacy IPI method when the h/w bug leaves a descriptor busy. -- new tunable: giveup_limit determines the threshold at which a hub is so plugged that it should do all requests with the legacy IPI method for a period of time -- generalize disable_for_congestion() (renamed disable_for_period()) for use whenever a hub should avoid using the BAU for a period of time Also: - Fix find_another_by_swack(), which is part of the UV2 bug workaround - Correct and clarify the statistics (new stats s_overipilimit, s_giveuplimit, s_enters, s_ipifordisabled, s_plugged, s_congested) Signed-off-by: Cliff Wickman <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-06-25x86/uv: Implement UV BAU runtime enable and disable control via /proc/sgi_uv/Cliff Wickman1-0/+2
This patch enables the BAU to be turned on or off dynamically. echo "on" > /proc/sgi_uv/ptc_statistics echo "off" > /proc/sgi_uv/ptc_statistics The system may be booted with or without the nobau option. Whether the system currently has the BAU off can be seen in the /proc file -- normally with the baustats script. Each cpu will have a 1 in the bauoff field if the BAU was turned off, so baustats will give a count of cpus that have it off. Signed-off-by: Cliff Wickman <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-06-08x86/uv: Fix UV2 BAU legacy modeCliff Wickman1-1/+0
The SGI Altix UV2 BAU (Broadcast Assist Unit) as used for tlb-shootdown (selective broadcast mode) always uses UV2 broadcast descriptor format. There is no need to clear the 'legacy' (UV1) mode, because the hardware always uses UV2 mode for selective broadcast. But the BIOS uses general broadcast and legacy mode, and the hardware pays attention to the legacy mode bit for general broadcast. So the kernel must not clear that mode bit. Signed-off-by: Cliff Wickman <[email protected]> Cc: <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-01-26x86/uv: Fix uv_gpa_to_soc_phys_ram() shiftRuss Anderson1-2/+2
uv_gpa_to_soc_phys_ram() was inadvertently ignoring the shift values. This fix takes the shift into account. Signed-off-by: Russ Anderson <[email protected]> Cc: <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>