Adrian Hunter [Fri, 16 Oct 2015 13:24:05 +0000 (16:24 +0300)]
perf/x86: Fix time_shift in perf_event_mmap_page
Commit:
b20112edeadf ("perf/x86: Improve accuracy of perf/sched clock")
allowed the time_shift value in perf_event_mmap_page to be as much
as 32. Unfortunately the documented algorithms for using time_shift
have it shifting an integer, whereas to work correctly with the value
32, the type must be u64.
In the case of perf tools, Intel PT decodes correctly but the timestamps
that are output (for example by perf script) have lost 32-bits of
granularity so they look like they are not changing at all.
Fix by limiting the shift to 31 and adjusting the multiplier accordingly.
Also update the documentation of perf_event_mmap_page so that new code
based on it will be more future-proof.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Fixes: b20112edeadf ("perf/x86: Improve accuracy of perf/sched clock") Link: http://lkml.kernel.org/r/1445001845-13688-2-git-send-email-adrian.hunter@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit b9511cd761faafca7a1acc059e792c1399f9d7c6)
Adrian Hunter [Fri, 21 Aug 2015 09:05:18 +0000 (12:05 +0300)]
perf/x86: Improve accuracy of perf/sched clock
When TSC is stable perf/sched clock is based on it.
However the conversion from cycles to nanoseconds
is not as accurate as it could be. Because
CYC2NS_SCALE_FACTOR is 10, the accuracy is +/- 1/2048
The change is to calculate the maximum shift that
results in a multiplier that is still a 32-bit number.
For example all frequencies over 1 GHz will have
a shift of 32, making the accuracy of the conversion
+/- 1/(2^33). That is achieved by using the
'clocks_calc_mult_shift()' function.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: http://lkml.kernel.org/r/1440147918-22250-1-git-send-email-adrian.hunter@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit b20112edeadf0b8a1416de061caa4beb11539902)
Keith Busch [Wed, 27 Apr 2016 20:22:32 +0000 (14:22 -0600)]
x86/apic: Handle zero vector gracefully in clear_vector_irq()
If x86_vector_alloc_irq() fails x86_vector_free_irqs() is invoked to cleanup
the already allocated vectors. This subsequently calls clear_vector_irq().
The failed irq has no vector assigned, which triggers the BUG_ON(!vector) in
clear_vector_irq().
We cannot suppress the call to x86_vector_free_irqs() for the failed
interrupt, because the other data related to this irq must be cleaned up as
well. So calling clear_vector_irq() with vector == 0 is legitimate.
Remove the BUG_ON and return if vector is zero,
[ tglx: Massaged changelog ]
Fixes: b5dc8e6c21e7 "x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors" Signed-off-by: Keith Busch <keith.busch@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 1bdb8970392a68489b469c3a330a1adb5ef61beb)
Ashok Vairavan [Tue, 2 May 2017 22:01:21 +0000 (15:01 -0700)]
Re-enable SDP for uek-nano kernel
SDP is enabled in the UEK config, but not in the uek-nano config.
Sockets Direct Protocol (SDP) is a network protocol which provides
an RDMA accelerated alternative to TCP over infiniband networks.
Newly allocated XFS metadata buffers are added to the LRU once the hold
count is released, which typically occurs after I/O completion. There is
no other mechanism at current that tracks the existence or I/O state of
a new buffer. Further, readahead I/O tends to be submitted
asynchronously by nature, which means the I/O can remain in flight and
actually complete long after the calling context is gone. This means
that file descriptors or any other holds on the filesystem can be
released, allowing the filesystem to be unmounted while I/O is still in
flight. When I/O completion occurs, core data structures may have been
freed, causing completion to run into invalid memory accesses and likely
to panic.
This problem is reproduced on XFS via directory readahead. A filesystem
is mounted, a directory is opened/closed and the filesystem immediately
unmounted. The open/close cycle triggers a directory readahead that if
delayed long enough, runs buffer I/O completion after the unmount has
completed.
To address this problem, add a mechanism to track all in-flight,
asynchronous buffers using per-cpu counters in the buftarg. The buffer
is accounted on the first I/O submission after the current reference is
acquired and unaccounted once the buffer is returned to the LRU or
freed. Update xfs_wait_buftarg() to wait on all in-flight I/O before
walking the LRU list. Once in-flight I/O has completed and the workqueue
has drained, all new buffers should have been released onto the LRU.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit 9c7504aa72b6e2104ba6dcef518c15672ec51175) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
The upcoming buftarg I/O accounting mechanism maintains a count of
all buffers that have undergone I/O in the current hold-release
cycle. Certain buffers associated with core infrastructure (e.g.,
the xfs_mount superblock buffer, log buffers) are never released,
however. This means that accounting I/O submission on such buffers
elevates the buftarg count indefinitely and could lead to lockup on
unmount.
Define a new buffer flag to explicitly exclude buffers from buftarg
I/O accounting. Set the flag on the superblock and associated log
buffers.
Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit c891c30a4dd1a236bb98630b35fc2769c5ce0d40) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
When committing era metadata to disk, it doesn't always save the latest
spacemap metadata root in superblock. Due to this, metadata is getting
corrupted sometimes when reopening the device. The correct order of update
should be, pre-commit (shadows spacemap root), save the spacemap root
(newly shadowed block) to in-core superblock and then the final commit.
Cc: stable@vger.kernel.org Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit 117aceb030307dcd431fdcff87ce988d3016c34a) Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
When both the parent and send snapshots have a directory inode with the
same number but different generations (therefore they are different
inodes) and both have an entry with the same name, an incremental send
stream will contain an invalid rmdir operation that refers to the
orphanized name of the inode from the parent snapshot.
The following example scenario shows how this happens.
Parent snapshot:
.
|---- d259_old/ (ino 259, gen 9)
| |---- d1/ (ino 258, gen 9)
|
|---- f (ino 257, gen 9)
Send snapshot:
.
|---- d258/ (ino 258, gen 7)
|---- d259/ (ino 259, gen 7)
|---- d1/ (ino 257, gen 7)
When the kernel is processing inode 258 it notices that in both snapshots
there is an inode numbered 259 that is a parent of an inode 258. However
it ignores the fact that the inodes numbered 259 have different generations
in both snapshots, which means they are effectively different inodes.
Then it checks that both inodes 259 have a dentry named "d1" and because
of that it issues a rmdir operation with orphanized name of the inode 258
from the parent snapshot. This happens at send.c:process_record_refs(),
which calls send.c:did_overwrite_first_ref() that returns true and because
of that later on at process_recorded_refs() such rmdir operation is issued
because the inode being currently processed (258) is a directory and it
was deleted in the send snapshot (and replaced with another inode that has
the same number and is a directory too).
Fix this issue by comparing the generations of parent directory inodes
that have the same number and make send.c:did_overwrite_first_ref() when
the generations are different.
$ mkfs.btrfs -f /dev/sdc
$ mount /dev/sdc /mnt
$ mkdir /mnt/d1
$ mkdir /mnt/dir258
$ mkdir /mnt/dir259
$ mv /mnt/d1 /mnt/dir259/d1
$ btrfs subvolume snapshot -r /mnt /mnt/snap2
$ btrfs receive /mnt/ -f /tmp/1.snap
# Take note that once the filesystem is created, its current
# generation has value 7 so the inodes from the second snapshot all have
# a generation value of 7. And after receiving the first snapshot
# the filesystem is at a generation value of 10, because the call to
# create the second snapshot bumps the generation to 8 (the snapshot
# creation ioctl does a transaction commit), the receive command calls
# the snapshot creation ioctl to create the first snapshot, which bumps
# the filesystem's generation to 9, and finally when the receive
# operation finishes it calls an ioctl to transition the first snapshot
# (snap1) from RW mode to RO mode, which does another transaction commit
# and bumps the filesystem's generation to 10. This means all the inodes
# in the first snapshot (snap1) have a generation value of 9.
$ rm -f /tmp/1.snap
$ btrfs send /mnt/snap1 -f /tmp/1.snap
$ btrfs send -p /mnt/snap1 /mnt/snap2 -f /tmp/2.snap
$ umount /mnt
Signed-off-by: Robbie Ko <robbieko@synology.com> Reviewed-by: Filipe Manana <fdmanana@suse.com>
[Rewrote changelog to be more precise and clear] Signed-off-by: Filipe Manana <fdmanana@suse.com>
(cherry picked from commit 0191410158840d6176de3267daa4604ad6a773fb) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
The upstream commit 8e3b21b6dbf0 (x86/platform/uv/BAU: Cleanup
bau_operations declaration and instances) has declared the
bau_operations ops instance with __ro_after_init. It can be safely
removed now as "ops" is an already existing variable and also the code that
supports this "read-only after init" feature is not pulled in yet.
The upstream commit c74ba8b3480d (arch: Introduce post-init read-only
memory) and several of its associated commits introduce this feature
from 4.6 kernel. When this feature is pulled in, this commit can be
reverted to make "bau_operations ops" read-only.
Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Remove the WARNING message associated with multiple NMI handlers as
there are at least two that are legitimate. These are the KGDB and the
UV handlers and both want to be called if the NMI has not been claimed
by any other NMI handler.
Use of the UNKNOWN NMI call chain dramatically lowers the NMI call rate
when high frequency NMI tools are in use, notably the perf tools. It is
required on systems that cannot sustain a high NMI call rate without
adversely affecting the system operation.
Signed-off-by: Mike Travis <mike.travis@hpe.com> Reviewed-by: Dimitri Sivanich <dimitri.sivanich@hpe.com> Cc: Don Zickus <dzickus@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Russ Anderson <russ.anderson@hpe.com> Cc: Frank Ramsay <frank.ramsay@hpe.com> Cc: Tony Ernst <tony.ernst@hpe.com> Link: http://lkml.kernel.org/r/20170307210841.730959611@asylum.americas.sgi.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 0d443b70cc92d741cbc1dcbf1079897b3d8bc3cc) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
UV4 does not employ a software-timeout as in previous generations so a new
wait_completion routine without this logic is required. Certain completion
statuses require the AUX status bit in addition to ERROR and BUSY.
Add the read_status routine to construct the full completion status. Use
read_status in the uv4_wait_completion routine to handle all possible
completion statuses.
Signed-off-by: Andrew Banman <abanman@hpe.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: sivanich@hpe.com Cc: rja@hpe.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/1489077734-111753-7-git-send-email-abanman@hpe.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 2f2a033fb5819c393d65da9b6233e095f3690f15) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
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 <abanman@hpe.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: sivanich@hpe.com Cc: rja@hpe.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/1489077734-111753-6-git-send-email-abanman@hpe.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 2620bbbf1f4f187952fb35861f4473860c432728) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
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 <abanman@hpe.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: sivanich@hpe.com Cc: rja@hpe.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/1489077734-111753-5-git-send-email-abanman@hpe.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit dfeb28f068ff9cc4f714c7d1edaf61597ea1768b) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
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 <abanman@hpe.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: sivanich@hpe.com Cc: rja@hpe.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/1489077734-111753-4-git-send-email-abanman@hpe.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 8e3b21b6dbf0318d5b3a598572acc23f07189c40) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
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 <abanman@hpe.com> Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: sivanich@hpe.com Cc: rja@hpe.com Cc: akpm@linux-foundation.org Link: http://lkml.kernel.org/r/1489077734-111753-3-git-send-email-abanman@hpe.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit e9be36443cecda1be20b2cc3b891676ff2af9dff) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
Writing to the software acknowledge clear register when there are no
pending messages causes a HUB error to assert. The original intent of this
write was to clear the pending bits before start of operation, but this is
an incorrect method and has been determined to be unnecessary.
Signed-off-by: Andrew Banman <abanman@hpe.com> Acked-by: Mike Travis <mike.travis@hpe.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: akpm@linux-foundation.org Cc: rja@hpe.com Cc: sivanich@hpe.com Link: http://lkml.kernel.org/r/1487351269-181133-1-git-send-email-abanman@hpe.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 1b17c6df852851b40c3c27c66b8fa2fd99cf25d8) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Jack Vogel <jack.vogel@oracle.com>
The IO and Abort latency counter count the time taken to complete
the IO and abort command into broad buckets. It is not intend for
performance measurement, just a debug stat.
current_max_io_time tries to keep tarck of the maximun time an IO
has taken to complete if it > 30sec, it just another debug stat.
Just a simple counter of number of check conditions encountered on
that host.
Signed-off-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
If SCSI-ML has already issued abort on a command i.e
FNIC_IOREQ_ABTS_PENDING is set and we get a IO completion avoid
this being flagged as out-of-order completion by setting the
FNIC_IO_DONE flag in fnic_fcpio_icmnd_cmpl_handler
Signed-off-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Vivek Goyal [Fri, 20 May 2016 13:04:26 +0000 (09:04 -0400)]
ovl: Do d_type check only if work dir creation was successful
d_type check requires successful creation of workdir as iterates
through work dir and expects work dir to be present in it. If that's
not the case, this check will always return d_type not supported even
if underlying filesystem might be supporting it.
So don't do this check if work dir creation failed in previous step.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
(cherry picked from commit 21765194cecf2e4514ad75244df459f188140a0f) Signed-off-by: Divya Indi <divya.indi@oracle.com>
Orabug: 25802620
Vivek Goyal [Mon, 22 Feb 2016 14:28:34 +0000 (09:28 -0500)]
ovl: Ensure upper filesystem supports d_type
In some instances xfs has been created with ftype=0 and there if a file
on lower fs is removed, overlay leaves a whiteout in upper fs but that
whiteout does not get filtered out and is visible to overlayfs users.
And reason it does not get filtered out because upper filesystem does
not report file type of whiteout as DT_CHR during iterate_dir().
So it seems to be a requirement that upper filesystem support d_type for
overlayfs to work properly. Do this check during mount and fail if d_type
is not supported.
Suggested-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
(cherry picked from commit 45aebeaf4f67468f76bedf62923a576a519a9b68) Signed-off-by: Divya Indi <divya.indi@oracle.com>
Orabug: 25802620
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Reviewed-by: Khalid Aziz <khalid.aziz@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Dave Aldridge [Fri, 3 Feb 2017 10:24:54 +0000 (02:24 -0800)]
sparc64: Stop performance counter before updating
This commit takes the fix as implemented in commit b36dd4d8040c and applies it to M8 devices. Original commit
message:
In order to reliably clear the PCRx.ov bit when updating a
performance counter value, we need to stop it counting first.
If we do not do this, then we can miss performance counter
overflow events.
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Dave Aldridge [Fri, 3 Feb 2017 14:38:46 +0000 (06:38 -0800)]
sparc64: Fix a race condition when stopping performance counters
This commit takes the fix as implemented in commit e5b7619e1de2 and applies it to M8 devices. Original commit
message:
When stopping a performance counter that is close to overflowing,
there is a race condition that can occur between writing to the
PCRx register to stop the counter (and also clearing the PCRx.ov
bit at the same time) vs the performance counter overflowing and
setting the PCRx.ov bit in the PCRx register.
The result of this race condition is that we occasionally miss
a performance counter overflow interrupt, which in turn leads
to incorrect event counting.
This race condition has been observed when counting cpu cycles.
To fix this issue when stopping a performance counter,
we simply allow it to continue counting and overflow before
stopping it. This allows the performance counter overflow
interrupt to be generated and acted upon.
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Allen Pais [Mon, 15 May 2017 13:46:23 +0000 (19:16 +0530)]
arch/sparc: Use new misaligned load instructions for memcpy and copy_from_user
Use the new instructions for Load Misaligned Integer and Load Misaligned
Integer Alternate space for M8 architecture.
Decide when to use FP or ldm based on the following condition.
In case of FP load/alignaddr logic, there is a fixed overhead of
FP save/restore regardless of memcpy length. But the overhead due to the
ldm instruction grows with the size of memcpy. With our tests noticed
that up to length about 4096, the ldm instructions performs significanty
better than the FP alignaddr/load logic. With that into consideration,
use the new ldm instructions for length of 4096 or less. For lengths
above 4096, we will continue to use FP alignaddr/load logic.
Added the fix noticed crypto key corruption while running AES crypto tests.
This is the same problem reported in NG4memcpy. The commit f4da3628dc7c
("sparc64: Fix FPU register corruption with AES crypto offload.") fixes
the problem. Ported these changes to M8memcpy and verified the fix.
TODO: Encoded the ldmx and ldmxa instruction for now. Our build servers
are not updated with latest M8 instruction set yet. We need to decode it
back to assembly mnemonics when these instructions are available.
Allen Pais [Mon, 15 May 2017 12:48:34 +0000 (18:18 +0530)]
arch/sparc: Add a separate kernel memcpy functions for M8
Add a dedicated kernel memory copy functions for M8 architecture.
Use M7memcpy functions from M7 architecture and update affected functions
to take advantage of new Load Misaligned load/store instructions.
Following functions are going to be affected.
memcpy, copy_from_user and copy_to_user.
Following functions will not change. Will remain same as M7.
clear_page, clear_user_page, memset and bzero.
Dave Aldridge [Fri, 2 Dec 2016 16:50:44 +0000 (08:50 -0800)]
sparc64: perf: make sure we do not set the 'picnht' bit in the PCR
Testing with the perf_fuzzer tool revealed an issue when the 'picnht' bit
was set in the Performance Control Register. Setting this bit means that
privileged software cannot access the PIC counter and we eventually end up
with messages of the form shown below, being reported.
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Dave Aldridge [Fri, 7 Oct 2016 14:57:50 +0000 (07:57 -0700)]
sparc64: perf: Fix the mapping between perf events and perf counters
Up until now, perf event[0] has been counted on perf counter[0],
perf event[1] on perf counter[1] etc. However, there is no reason why
this has to be the case. Infact, on SPARC-M8 some events can only be
counted on a sub set of the available perf counters, rather than all
the available perf counters. Whilst adding these perf counter
constraints for the SPARC-M8 it became apparent that some confusion
had crept into the existing code.
Some functions were making the assumption that the perf event index was
equivalent to the perf counter index. This commit fixes these assumptions,
and allows for the case where perf event[0] is not counted on
perf counter[0] etc.
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Allen Pais [Tue, 16 May 2017 07:14:47 +0000 (12:44 +0530)]
SPARC64: Enable IOMMU bypass for IB
This change enables IOMMU bypass for Infiniband devices to workaround
the rds-stress performance issue. The performance slowdown is only
seen with rds-stress test. This test generates rigorous amount of dma
map/unmap calls. Investigation shows that somewhere IOMMU/ATU code
doesn't scale and appears to be a bottleneck.
This is for uek4 only and not for upstream. When IOMMU/ATU issue gets
resolved, this workaround will be reverted.
Waiman Long [Wed, 2 Dec 2015 18:41:50 +0000 (13:41 -0500)]
sched/fair: Disable the task group load_avg update for the root_task_group
Currently, the update_tg_load_avg() function attempts to update the
tg's load_avg value whenever the load changes even for root_task_group
where the load_avg value will never be used. This patch will disable
the load_avg update when the given task group is the root_task_group.
Running a Java benchmark with noautogroup and a 4.3 kernel on a
16-socket IvyBridge-EX system, the amount of CPU time (as reported by
perf) consumed by task_tick_fair() which includes update_tg_load_avg()
decreased from 0.71% to 0.22%, a more than 3X reduction. The Max-jOPs
results also increased slightly from 983015 to 986449.
Atish Patra [Wed, 22 Mar 2017 22:22:01 +0000 (16:22 -0600)]
sched/fair: Move the cache-hot 'load_avg' variable into its own cacheline
If a system with large number of sockets was driven to full
utilization, it was found that the clock tick handling occupied a
rather significant proportion of CPU time when fair group scheduling
and autogroup were enabled.
Running a java benchmark on a 16-socket IvyBridge-EX system, the perf
profile looked like:
In particular, the high CPU time consumed by update_cfs_shares()
was mostly due to contention on the cacheline that contained the
task_group's load_avg statistical counter. This cacheline may also
contains variables like shares, cfs_rq & se which are accessed rather
frequently during clock tick processing.
This patch moves the load_avg variable into another cacheline
separated from the other frequently accessed variables. It also
creates a cacheline aligned kmemcache for task_group to make sure
that all the allocated task_group's are cacheline aligned.
Waiman Long [Wed, 25 Nov 2015 19:09:38 +0000 (14:09 -0500)]
sched/fair: Avoid redundant idle_cpu() call in update_sg_lb_stats()
Part of the responsibility of the update_sg_lb_stats() function is to
update the idle_cpus statistical counter in struct sg_lb_stats. This
check is done by calling idle_cpu(). The idle_cpu() function, in
turn, checks a number of fields within the run queue structure such
as rq->curr and rq->nr_running.
With the current layout of the run queue structure, rq->curr and
rq->nr_running are in separate cachelines. The rq->curr variable is
checked first followed by nr_running. As nr_running is also accessed
by update_sg_lb_stats() earlier, it makes no sense to load another
cacheline when nr_running is not 0 as idle_cpu() will always return
false in this case.
This patch eliminates this redundant cacheline load by checking the
cached nr_running before calling idle_cpu().
Atish Patra [Wed, 22 Mar 2017 21:55:24 +0000 (15:55 -0600)]
sched/fair: Clean up load average references
For cfs_rq, we have load.weight, runnable_load_avg, and load_avg.
Clean up how they are used:
- First, as group sched_entity already largely uses load_avg, we now expand
to use load_avg in all cases.
- Second, for CPU-wide load balancing, we choose to use runnable_load_avg
in all cases, which is the same as before this series.
[Atish]:
Here is the conflict in this patch.
<<<<<<< HEAD
unsigned long nr_running = ACCESS_ONCE(rq->cfs.h_nr_running);
unsigned long load_avg = rq->cfs.avg.load_avg;
=======
unsigned long nr_running = READ_ONCE(rq->cfs.h_nr_running);
unsigned long load_avg = weighted_cpuload(cpu);
>>>>>>> 7ea241a... sched/fair: Clean up load average references
ACCESS_ONCE is replaced with READ_ONCE by the upstream patch 316c1608d15c7.
As this patch is not in UEK4, ACCESS_ONCE is kept as it is.
Yuyang Du [Wed, 15 Jul 2015 00:04:41 +0000 (08:04 +0800)]
sched/fair: Provide runnable_load_avg back to cfs_rq
The cfs_rq's load_avg is composed of runnable_load_avg and blocked_load_avg.
Before this series, sometimes the runnable_load_avg is used, and sometimes
the load_avg is used. Completely replacing all uses of runnable_load_avg
with load_avg may be too big a leap, i.e., the blocked_load_avg is concerned
to result in overrated load. Therefore, we get runnable_load_avg back.
The new cfs_rq's runnable_load_avg is improved to be updated with all of the
runnable sched_eneities at the same time, so the one sched_entity updated and
the others stale problem is solved.
Yuyang Du [Wed, 15 Jul 2015 00:04:40 +0000 (08:04 +0800)]
sched/fair: Remove task and group entity load when they are dead
When task exits or group is destroyed, the entity's load should be
removed from its parent cfs_rq's load. Otherwise, it will take time
for the parent cfs_rq to decay the dead entity's load to 0, which
is not desired.
Yuyang Du [Wed, 15 Jul 2015 00:04:39 +0000 (08:04 +0800)]
sched/fair: Init cfs_rq's sched_entity load average
The runnable load and utilization averages of cfs_rq's sched_entity
were not initiated. Like done to a task, give new cfs_rq' sched_entity
start values to heavy its load in infant time.
Atish Patra [Wed, 22 Mar 2017 20:51:40 +0000 (14:51 -0600)]
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
[Atish:]
This patch moved some of the conflicting functions from proc.c to
fair.c and removed the corresponding declarations from sched.h.
The upstream patch 3289bdb42988 moved these functions from proc.c to
fair.c in addition to lot of other code restructure. Porting 3289bdb42988
breaks KABI for UEK4. That's why I have to hack around it.
Khalid Aziz [Mon, 8 May 2017 22:17:43 +0000 (16:17 -0600)]
sparc64: Allow enabling ADI on hugepages only
Since kernel provides only limted support for ADI on regular pages,
mprotect() should not allow enabling ADI on any pages other than
hugepages until rest of the support is complete.
Orabug: 25969377 Signed-off-by: Khalid Aziz <khalid.aziz@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Khalid Aziz [Thu, 27 Apr 2017 17:40:04 +0000 (11:40 -0600)]
sparc64: Save ADI tags on ADI enabled platforms only
When a page is ready to be swapped out or migrated, kernel saves the
ADI tags associated with it. To determine if ADI tags need to be saved
for a page, it checks if TTE.MCD bit is set for the page. M7 and newer
processors chose to reuse the TTE.CV bit from older processors for
TTE.MCD. When the kernel is running on non-ADI capable processors,
TTE.MCD bit is actually TTE.CV and it is set on older processors by
default for older processors by kernel. This causes kernel to
attempt to save the ADI tags for the page using MCD ASIs which are
not available on older processors. This causes a data access exception.
This patch adds a conditional to save ADI tags only on ADI capable
platforms.
Some larger applications require a TSB size of magnitude not required by a
vast majority of processes. This commit enables the TSB to be expanded
to a size up to MAX_ORDER - 1, limited by TSB size order encoding and
finally limited by MMU hardware. The large TSB page order allocations are
not included in a kmem cache like current TSB sizes. The improvement is
done for tlb_type hypervisor and limited to recent sun4v. This patch should
not impact performance of other sparc64 core chip types.
Signed-off-by: Bob Picco <bob.picco@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Thomas Tai [Thu, 6 Apr 2017 17:29:03 +0000 (10:29 -0700)]
sparc64: fix intermittent LDom hang waiting for vdc_port_up
When LDom boots, sunvdc probes the disk using the LDC channel.
If the channel was previously configured, we need to wait until
we have received a packet from the other end to ensure the
the LDC reset was fully completed; otherwise, the primary domain
will send out NACK when vdc tries to connect. The NACK causes
ldc_reset and flushes the receive queue which may contain the
version info. The unexpected loss of version info causes
the vdc handshake to wait forever.
This patch is to workaround the ldc_reset not handling
reconnection after receiving a NACK. This patch can be
reverted after ldc_reset is properly implemented.
Signed-off-by: Thomas Tai <thomas.tai@oracle.com> Reviewed-by: Tom Saeger <tom.saeger@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Reviewed-by: Babu Moger <babu.moger@oracle.com> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Vijay Kumar [Mon, 23 Jan 2017 17:53:03 +0000 (09:53 -0800)]
sparc64:block/sunvdc: Renamed bio variable name from req to bio
Changed bio variable name from req to bio for better readability.
This is just a cosmetic change.
Signed-off-by: Vijay Kumar <vijay.ac.kumar@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Orabug: 25128265 Signed-off-by: Allen Pais <allen.pais@oracle.com>
Vijay Kumar [Wed, 18 Jan 2017 16:10:12 +0000 (08:10 -0800)]
sparc64:block/sunvdc: Added io stats accounting for bio based vdisk
As vdisk now bypass block layer and directly submits IO, iostats does
not get accounted (which happens at block). Added IO accounting at bio
layer for vdisk block device.
Signed-off-by: Vijay Kumar <vijay.ac.kumar@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Orabug: 25128265 Signed-off-by: Allen Pais <allen.pais@oracle.com>
chris hyser [Wed, 15 Mar 2017 17:51:34 +0000 (10:51 -0700)]
sparc64: Remove node restriction from PRIQ MSI assignments
The current design of PRIQ only allows MSI routing to CPUs within the same
I/O node. At best this prevents certain types of CPU add/removals as well
as various affinity assignments and at worst can result in dropped
interrupts with CPU DR.
This prior design used a per-node hash table with collision chain (and RCU
synchronization) shared among the root complexes. While it would be
possible to support moving these records between the node hash tables this
is needlessly complicated when a single global table could be used instead
assuming the hashing mechanism was modified to limit the potential for
performance degradation through potentially longer collision chains and
more lookups.
The new design for MSI uses the bottom N bits of the device handle as a
hash versus hashing device handle and msidata together as before. This
exploits the existing numbering scheme to result in zero collisions (even
in an exactly sized hash table). If the numbering scheme is changed on a
future system, that system will still be functional though presumably
with some performance loss. The MSI data is then used as an index into a
array as has been done for prior linux sun4v interrupt model support. Given
the very small number of INTX interrupts, their handling remains
essentially unchanged (now uses a single global hash table, versus per I/O
node as before).
chris hyser [Fri, 3 Mar 2017 21:24:22 +0000 (13:24 -0800)]
blk-mq: Clean up all_q_list on request_queue deletion
Entries were not being removed from all_q_list when corresponding request
queue structs were freed with subsequent embedded list pointers being
trashed when the queue memory was re-allocated. Additionally, due to use of
cached allocation pool (kmem_cache_alloc_node), the same data structure
would be reinserted into the same list twice which cannot work given the
kernel linked list implementation.
Signed-off-by: Chris Hyser <chris.hyser@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com>
Orabug: 25569331 Signed-off-by: Allen Pais <allen.pais@oracle.com>
I encountered this bug when using /proc/kcore to examine the kernel. Plus a
coworker inquired about debugging tools. We computed pa but did
not use it during the maximum physical address bits test. Instead we used
the identity mapped virtual address which will always fail this test.
I believe the defect came in here:
[bpicco@zareason linus.git]$ git describe --contains bb4e6e85daa52
v3.18-rc1~87^2~4
.
Signed-off-by: Bob Picco <bob.picco@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Chuck Anderson [Fri, 5 May 2017 16:57:23 +0000 (09:57 -0700)]
Merge branch topic/uek-4.1/sparc of git://ca-git.us.oracle.com/linux-uek into uek/uek-4.1
* topic/uek-4.1/sparc: (32 commits)
sparc64: Detect DAX ra+pgsz when hvapi minor doesn't indicate it
sparc64: DAX memory will use RA+PGSZ feature in HV
sparc64: Disable DAX flow control
sparc64: Add DAX hypervisor services
sparc64: DAX memory needs persistent mappings
sparc64: Fix incorrect error print in DAX driver when validating ccb
sparc64: DAX request for non 4MB memory should return with unique errno
Revert "sparc64: DAX request for non 4MB memory should return with unique errno"
sparc64: DAX request to mmap non 4MB memory should fail with a debug print
sparc64: DAX request for non 4MB memory should return with unique errno
sparc64: Incorrect print by DAX driver when old driver API is used
sparc64: DAX request to dequeue half of a long CCB should not succeed
sparc64: dax_overflow_check reports incorrect data
sparc64: Ignored DAX ref count causes lockup
sparc64: disable dax page range checking on RA
sparc64: Oracle Data Analytics Accelerator (DAX) driver
sparc64: fix an issue when trying to bring hotplug cpus online
sparc64: Fix memory corruption when THP is enabled
sparc64: Fix address range for page table free Orabug: 25704426
sparc64: Add support for 2G hugepages
...
The RA+PGSZ HV API feature is detected via a controlled experiment.
The experiment constructs a small DAX request and places the output
buffer at the very end of an 8k page. Then it checks to see if the 8k
page boundary was honored, and if so, then we've got the ability to pass
the page size along with a real address. Once the HV API minor number
is bumped to 1, this will be the primary method of detection.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com>
(cherry picked from commit 013d5b9909e804817dcd939f50f242f09237feac) Signed-off-by: Allen Pais <allen.pais@oracle.com>
The reported kernel panics and "other oddities" are caused by
corruption of kernel memory by DAX output. This is happening due to an
apparent change between UEK2 and UEK4, whereby the underlying h/w page
size for memory acquired via kmalloc has changed. UEK2 used 4mb pages,
which the dax driver used to limit the output from the coprocessor,
who refuses to cross "page boundaries". But in UEK4 it appears that a
more intelligent approach to memory is used, and kernel memory may be
backed by a variety of huge h/w page sizes, ie, 256mb and 2gb. This
now allows DAX to produce output up to this much larger page size,
thus going beyond the actual allocation. We do not have any way to
kmalloc memory with a certain backing page size, and we cannot feed
DAX a virtual address if we are not certain of its page size.
Recent hypervisor f/w has provided a powerful new feature: the ability
to convey page size bits along with a real address (RA). This gives us
the opportunity to avoid using the TLB/TSB as a parameter passing
mechanism and we can use this to avoid using virtual addresses at all
in a DAX ccb. We now use this mechanism to set the page size for
dax_alloc memory to 4mb even if the underlying h/w page size for the
memory is much larger. Memory allocated by the application via
conventional methods is not affected.
This HV feature is available on M7 f/w with minor number 1, so this is
used to determine if the driver can provide the memory allocation
service. If the feature is not available, DAX will still work, but all
the responsibility for memory allocation falls back to the
application.
The sudden ENOACCESS errors are a result of another hypervisor change.
Newest HV firmware has begun to enforce the privileged flag (bit 14)
in arg2 of the ccb_submit hypercall. This flag is described in the API
wiki as "CCB virtual addresses are treated as privileged" and in the
VM spec as "Virtual addresses within CCBs are translated in privileged
context". The explanation given later in the VM spec is that if a CCB
contains any virtual address whose TTE has the priv bit set
(_PAGE_P_4V), then the priv flag in the ccb_submit api must also be
set, or else the hypervisor will refuse to perform the translation,
and an ENOACCESS error will be thrown. Since privileged virtual
addresses are no longer used as a result of this very commit, this
problem simply disappears.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
The flow control feature of DAX only works for output buffers
and it doesn't appear to be possible to calculate the exact
size in bytes of an input buffer. So we have no way to bound
the amount of data that DAX reads as input. This has correctness
and security implications, so until we figure out something better
to do, the temporary workaround is to disable flow control completely
and fall back to 4Mb virtual page backed dax_alloc memory, which
will allow page boundaries to limit the size of all buffers. A new
module parameter "flow_enable" is provided to allow this decision
to be reverted at module load time if needed.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com> Reviewed-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Reviewed-by: Bob Picco <bob.picco@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
fpu_activate is called outside of vcpu_load(), which means it should not
touch VMCS, but fpu_activate needs to. Avoid the call by moving it to a
point where we know that the guest needs eager FPU and VMCS is loaded.
Memory allocated on behalf of dax_alloc() is mapped by two
distinct MMU translations, one set for userland, which is backed by
regular 8k virtual pages, and another set for feeding to the
hypervisor, and these are kernel virtual addresses backed
by 4Mb pages. These latter translations are only used when
the memory is allocated/deallocated and when a dax transaction
is submitted. So the translations are unlikely to be in the TLB,
and eventually may be evicted from the kernel TSB after some time.
This leads to ENOMAP errors reported by the hypervisor. In order
to avoid this, we "touch" such pages just before dax_submit
which will fault translations into the tlb/tsb if necessary.
A future performance optimization is to take advantage of the "real
address has pagesize" feature which is available in very recent
versions of hypervisor f/w. In this case we can convert the address
in the ccb to a real address with the correct bits to specify
a 4Mb pagesize, and change the address type to real. Then the
memory touch would be unnecessary and the HV would not need to
probe the tlb/tsb at all.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: HÃ¥kon Bugge <haakon.bugge@oracle.com> Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
This fixes an incorrect stringification in a macro that prints
invalid address type in a CCB.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
With this change libdax can detect that mmap failed due to lack of flow
control in DAX HW and it can proceed with dax_subpage allocation.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
When the dax flow control is disabled, dax_alloc_mem(...) only allows 4MB
allocation in the driver. Any other requests are reported as an error
with an error print to the kernel log. We now have a dax subpage
allocator in libdax which gets triggered when the driver reports the
above said failure. In other words it is a normal use case for the driver
to report this. So make this a debug print.
Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
With this change libdax can detect that mmap failed due to lack of flow
control in DAX HW and it can proceed with dax_subpage allocation.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
If an old dax driver API is used, it is the driver API version
that is old, irrespective of the libdax version.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
When a dequeue call is made to the driver such that the last CCB in the
request is the first half of a long ccb, the driver does not report an
error and releases the BIP buffer for the CCBs dequeued up until then.
This was detected by a ioctl_test23 written by Stanislav specifically to
validate the above scenario.
This bug fix addresses both the above issues.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
The range reported for a page overflow is incorrect when
the address is page_size aligned. Add 1 to the address so
that it always reports the next page_size boundary.
Reviewed-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
The dax_mm structure has a reference count that respresents
the number of dax_vma structures that point to it. The reference
count is duly incremented and decremented each time memory is
allocated via the dax_alloc/mmap path. However, the reference
count is never used for its intended purpose, which is to
prevent the dax_mm structure from being freed while there
are references to it. The result of this is that if dax_free
is called after the process's dax_mm is cleaned up, the dax_vma
will have a reference to the freed object, leading to panics
due to null pointers and/or lockups due to inalid spinlock state.
Code changed to actually check the reference count before freeing
a dax_mm.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
This fix is to address a hypervisor f/w change which affects
T7 machines with 3.0 cpu and T8 machines. Newer HV f/w
pays attention to the page size field in real addresses.
This is not a bug; I asked them to implement this long ago.
A value of zero here means 8k, so RA buffers are restricted
to one page when running on newer firmware. The PRM defines a page
size of 0xF to mean "disable page range checking". We set this
value for all real addresses. Old f/w will overwrite this field
anyway, so it's safe for us to always set it.
Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
DAX is a coprocessor which resides on the SPARC M7 processor chip, and
has direct access to the CPU's L3 caches as well as physical
memory. It can perform several operations on data streams with
various input and output formats. The driver is merely a transport
mechanism and does not have knowledge of the various opcodes and data
formats. A user space library provides high level services and
translates these into low level commands which are then passed into
the driver and subsequently the hypervisor and the coprocessor.
See Documentation/sparc/dax.txt for more details.
Reviewed-by: Jonathan Helman <jonathan.helman@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Reviewed-by: David Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com> Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Dave Aldridge [Fri, 24 Mar 2017 12:01:00 +0000 (06:01 -0600)]
sparc64: fix an issue when trying to bring hotplug cpus online
When booting the kernel with maxcpus= on the command line
and then subsequently trying to bring cpus online using:
echo 1 > /sys/devices/system/cpu/cpu[n]/online
messages of the form:
ldom_startcpu_cpuid: sun4v_cpu_start() gives error 6
Processor[n] is stuck
were being reported on the console.
This commit fixes this issue by ensuring that any cpus not
booted during initial kernel boot are explicitly stopped.
This then allows them to be successfully brought online later
if required.
Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Reviewed-by: Allen Pais <allen.pais@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Reported-by: David S. Miller <davem@davemloft.net> Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Jagannathan Raman <jag.raman@oracle.com> Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Reviewed-by: Bijan Mottahedeh <bijan.mottahedeh@oracle.com> Reviewed-by: Jack Schwartz <jack.schwartz@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
George Kennedy [Wed, 22 Mar 2017 17:39:32 +0000 (13:39 -0400)]
SPARC64: Virtual Disk Device (vdsdev) Read-Only Option (options=ro) not working
Add read-only (options=ro) support to virtual disk server (VDS).
Signed-off-by: George Kennedy <george.kennedy@oracle.com> Reviewed-by: Alexandre Chartre <Alexandre.Chartre@oracle.com>
Orabug: 23623853 Signed-off-by: Allen Pais <allen.pais@oracle.com>
Babu Moger [Tue, 7 Mar 2017 22:19:55 +0000 (14:19 -0800)]
arch/sparc: Fix FPU register corruption with AES crypto test on M7
We noticed crypto key corruption while running AES crypto tests
with M7 memcpy changes. Investigating further, we found that this
was the same problem reported previously with NG4memcpy. The commit f4da3628dc7c ("sparc64: Fix FPU register corruption with AES crypto
offload") fixes the problem. Ported these changes to M7memcpy.
Signed-off-by: Babu Moger <babu.moger@oracle.com> Tested-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Shannon Nelson [Tue, 14 Mar 2017 17:24:43 +0000 (10:24 -0700)]
sunvnet: xoff not needed when removing port link
The sunvnet netdev is connected to the controlling ldom's vswitch
for network bridging. However, for higher performance between ldoms,
there also is a channel between each client ldom. These connections are
represented in the sunvnet driver by a queue for each ldom. The driver
uses select_queue to tell the stack which queue to use by tracking the mac
addresses on the other end of each port. When a connected ldom shuts down,
the driver receives an LDC_EVENT_RESET and the port is removed from the
driver, thus a queue with no ldom on the other end will never be selected
for Tx.
The driver was trying to reinforce the "don't use this queue" notion with
netif_tx_stop_queue() and netif_tx_wake_queue(), which really should only
be used to signal a Tx queue is full (aka XOFF). This misuse of queue
state resulted in NETDEV WATCHDOG messages and lots of unnecessary calls
into the driver's tx_timeout handler. Simply removing these takes care
of the problem.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry-picked from commit 9c5a3a1f9388100d4b03e85faf0cce8264985302)
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry-picked from commit b12a96f5cd04583f45a1b6554b8f3786b26db913)
Shannon Nelson [Tue, 14 Mar 2017 17:24:41 +0000 (10:24 -0700)]
sunvnet: track port queues correctly
Track our used and unused queue indexies correctly. Otherwise, as ports
dropped out and returned, they all eventually ended up with the same
queue index.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry-picked from commit e1f1e5f711265ee9d881afd12ff252b2d01e1174)
projects / users / jedix / linux-maple.git / log