Commit-ID: d47d77c3f008d3cf02c6ce92ef4f6e32ca270351
Gitweb: https://git.kernel.org/tip/d47d77c3f008d3cf02c6ce92ef4f6e32ca270351
Author: Davidlohr Bueso
AuthorDate: Fri, 9 Nov 2018 13:07:19 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 21 Nov 2018 12:00:32 -0300
perf bench
This is already done for us internally by the signal machinery.
Cc: pet...@infradead.org
Cc: mi...@kernel.org
Signed-off-by: Davidlohr Bueso
---
kernel/locking/mutex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index
This is already done for us internally by the signal machinery.
Signed-off-by: Davidlohr Bueso
---
mm/filemap.c | 2 +-
mm/gup.c | 2 +-
mm/hugetlb.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 81adec8ee02c..abd6c4591855 100644
This is already done for us internally by the signal machinery.
Cc: pet...@infradead.org
Cc: mi...@kernel.org
Signed-off-by: Davidlohr Bueso
---
kernel/locking/mutex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index
This is already done for us internally by the signal machinery.
Signed-off-by: Davidlohr Bueso
---
mm/filemap.c | 2 +-
mm/gup.c | 2 +-
mm/hugetlb.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 81adec8ee02c..abd6c4591855 100644
This is already done for us internally by the signal machinery.
Cc: vgu...@synopsys.com
Signed-off-by: Davidlohr Bueso
---
arch/arc/mm/fault.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index c9da6102eb4f..6b6df8f9f882 100644
This is already done for us internally by the signal machinery.
Cc: pet...@infradead.org
Cc: mi...@kernel.org
Signed-off-by: Davidlohr Bueso
---
kernel/sched/core.c | 2 +-
kernel/sched/swait.c | 2 +-
kernel/sched/wait.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git
This is already done for us internally by the signal machinery.
Cc: linux-...@vger.kernel.org
Cc: p...@axentia.se
Signed-off-by: Davidlohr Bueso
---
drivers/i2c/busses/i2c-ibm_iic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers
folks want to pick up bits
separately.
Compile tested only. Please consider for v4.21.
Thanks!
Davidlohr Bueso (6):
locking/mutex: Remove caller signal_pending branch predictions
kernel/sched: Remove caller signal_pending branch predictions
arch/arc: Remove caller signal_pending_branch
This is already done for us internally by the signal machinery.
Cc: vgu...@synopsys.com
Signed-off-by: Davidlohr Bueso
---
arch/arc/mm/fault.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arc/mm/fault.c b/arch/arc/mm/fault.c
index c9da6102eb4f..6b6df8f9f882 100644
This is already done for us internally by the signal machinery.
Cc: pet...@infradead.org
Cc: mi...@kernel.org
Signed-off-by: Davidlohr Bueso
---
kernel/sched/core.c | 2 +-
kernel/sched/swait.c | 2 +-
kernel/sched/wait.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git
This is already done for us internally by the signal machinery.
Cc: linux-...@vger.kernel.org
Cc: p...@axentia.se
Signed-off-by: Davidlohr Bueso
---
drivers/i2c/busses/i2c-ibm_iic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers
folks want to pick up bits
separately.
Compile tested only. Please consider for v4.21.
Thanks!
Davidlohr Bueso (6):
locking/mutex: Remove caller signal_pending branch predictions
kernel/sched: Remove caller signal_pending branch predictions
arch/arc: Remove caller signal_pending_branch
This is already done for us internally by the signal machinery.
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: Davidlohr Bueso
---
fs/afs/fs_probe.c | 2 +-
fs/afs/vl_probe.c | 2 +-
fs/buffer.c | 2 +-
fs/exec.c | 4 ++--
fs
This is already done for us internally by the signal machinery.
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: Davidlohr Bueso
---
fs/afs/fs_probe.c | 2 +-
fs/afs/vl_probe.c | 2 +-
fs/buffer.c | 2 +-
fs/exec.c | 4 ++--
fs
On Sun, 11 Nov 2018, Paul E. McKenney wrote:
From: Lance Roy
lockdep_assert_held() is better suited to checking locking requirements,
since it only checks if the current thread holds the lock regardless of
whether someone else does. This is also a step towards possibly removing
On Sun, 11 Nov 2018, Paul E. McKenney wrote:
From: Lance Roy
lockdep_assert_held() is better suited to checking locking requirements,
since it only checks if the current thread holds the lock regardless of
whether someone else does. This is also a step towards possibly removing
On Wed, 14 Nov 2018, Andrew Morton wrote:
Why was this moved to before the ep_reset_busy_poll_napi_id() call?
That movement placed the code ahead of the block comment which serves
to explain its function.
Yikes, that was a brain fart.
This? Which also fixes that comment and reflows it to
On Wed, 14 Nov 2018, Andrew Morton wrote:
Why was this moved to before the ep_reset_busy_poll_napi_id() call?
That movement placed the code ahead of the block comment which serves
to explain its function.
Yikes, that was a brain fart.
This? Which also fixes that comment and reflows it to
There is no reason why we rearm the waitiqueue upon every
fetch_events retry (for when events are found yet send_events()
fails). If nothing else, this saves four lock operations per
retry, and furthermore reduces the scope of the lock even
further.
Signed-off-by: Davidlohr Bueso
---
fs
There is no reason why we rearm the waitiqueue upon every
fetch_events retry (for when events are found yet send_events()
fails). If nothing else, this saves four lock operations per
retry, and furthermore reduces the scope of the lock even
further.
Signed-off-by: Davidlohr Bueso
---
fs
It is currently called check_events because it, well, did
exactly that. However, since the lockless ep_events_available()
call, the label no longer checks, but just sends the events.
Rename as such.
Signed-off-by: Davidlohr Bueso
---
Both patch 1 and 2 apply on top of the mmots.
fs
It is currently called check_events because it, well, did
exactly that. However, since the lockless ep_events_available()
call, the label no longer checks, but just sends the events.
Rename as such.
Signed-off-by: Davidlohr Bueso
---
Both patch 1 and 2 apply on top of the mmots.
fs
On Sun, 11 Nov 2018, Arnaldo Carvalho de Melo wrote:
Gets it a bit further, then we get this, which I think should be fixed
using some PRIu64, etc. I'll try to do that at some point, but in short
vacations now, then plumbers :-)
Yeah sorry, I didn't mean to suggest that was it. I can send the
On Sun, 11 Nov 2018, Arnaldo Carvalho de Melo wrote:
Gets it a bit further, then we get this, which I think should be fixed
using some PRIu64, etc. I'll try to do that at some point, but in short
vacations now, then plumbers :-)
Yeah sorry, I didn't mean to suggest that was it. I can send the
ove HAVE_PTHREAD_ATTR_SETAFFINITY_NP into bench.h
Both futex and epoll need this call, and can cause build failure
on systems that don't have it pthread_attr_setaffinity_np().
Signed-off-by: Davidlohr Bueso
---
tools/perf/bench/bench.h | 11 +++
tools/perf/bench/futex.h | 12
2 fi
ove HAVE_PTHREAD_ATTR_SETAFFINITY_NP into bench.h
Both futex and epoll need this call, and can cause build failure
on systems that don't have it pthread_attr_setaffinity_np().
Signed-off-by: Davidlohr Bueso
---
tools/perf/bench/bench.h | 11 +++
tools/perf/bench/futex.h | 12
2 fi
On Fri, 09 Nov 2018, Todd Kjos wrote:
print_binder_proc() drops proc->inner_lock and calls
binder_alloc_print_allocated() which acquires proc->alloc->mutex.
Likewise, print_binder_stats() calls print_binder_proc_stats() which
drops its locks to call binder_alloc_print_pages() which also
On Fri, 09 Nov 2018, Todd Kjos wrote:
print_binder_proc() drops proc->inner_lock and calls
binder_alloc_print_allocated() which acquires proc->alloc->mutex.
Likewise, print_binder_stats() calls print_binder_proc_stats() which
drops its locks to call binder_alloc_print_pages() which also
der can get and if it matters at all.
Anyway, that said and along with addressing Todd's comments, the ipc/ bits look
good. Feel free to add my:
Reviewed-by: Davidlohr Bueso
Thanks,
Davidlohr
der can get and if it matters at all.
Anyway, that said and along with addressing Todd's comments, the ipc/ bits look
good. Feel free to add my:
Reviewed-by: Davidlohr Bueso
Thanks,
Davidlohr
Sorry, I just realized I forgot these fixlets when sending the v1.
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index ec14e5bcdaa9..c37729658c03 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -381,7 +381,7 @@ static void ep_nested_calls_init(struct nested_calls
*ncalls)
*/
static inline
Sorry, I just realized I forgot these fixlets when sending the v1.
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index ec14e5bcdaa9..c37729658c03 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -381,7 +381,7 @@ static void ep_nested_calls_init(struct nested_calls
*ncalls)
*/
static inline
On Wed, 07 Nov 2018, Davidlohr Bueso wrote:
I have not looked at how filesystems tune the batch size, but it would
certainly be worth
looking into methinks.
nm this part, percpu_counter_batch is not tunable. It would
still probably be acceptable (famous last words) to at least
move
On Wed, 07 Nov 2018, Davidlohr Bueso wrote:
I have not looked at how filesystems tune the batch size, but it would
certainly be worth
looking into methinks.
nm this part, percpu_counter_batch is not tunable. It would
still probably be acceptable (famous last words) to at least
move
On Thu, 08 Nov 2018, Dave Chinner wrote:
If only we had percpu counters that had a fixed, extremely low read
overhead that doesn't care about the number of CPUs in the
machine
Oh, wait, we do: percpu_counters.[ch].
This all seems like a counter implementation deficiency to me, not
an
On Thu, 08 Nov 2018, Dave Chinner wrote:
If only we had percpu counters that had a fixed, extremely low read
overhead that doesn't care about the number of CPUs in the
machine
Oh, wait, we do: percpu_counters.[ch].
This all seems like a counter implementation deficiency to me, not
an
On Mon, 29 Oct 2018, chouryzhou(??) wrote:
@@ -63,6 +63,12 @@ struct ipc_namespace {
unsigned intmq_msg_default;
unsigned intmq_msgsize_default;
+ /* next fields are for binder */
+ struct mutex binder_procs_lock;
+ struct hlist_head
On Mon, 29 Oct 2018, chouryzhou(??) wrote:
@@ -63,6 +63,12 @@ struct ipc_namespace {
unsigned intmq_msg_default;
unsigned intmq_msgsize_default;
+ /* next fields are for binder */
+ struct mutex binder_procs_lock;
+ struct hlist_head
On Wed, 07 Nov 2018, Bueso wrote:
On Mon, 29 Oct 2018, chouryzhou(??) wrote:
+// If init_ipc_ns is not defined elsewhere,
+// we make a fake one here to put our variable.
/*
* comments like this please
*/
Actually, just drop the comment altogether. Forward declaring does not merit it.
On Wed, 07 Nov 2018, Bueso wrote:
On Mon, 29 Oct 2018, chouryzhou(??) wrote:
+// If init_ipc_ns is not defined elsewhere,
+// we make a fake one here to put our variable.
/*
* comments like this please
*/
Actually, just drop the comment altogether. Forward declaring does not merit it.
On Mon, 29 Oct 2018, chouryzhou(??) wrote:
+// If init_ipc_ns is not defined elsewhere,
+// we make a fake one here to put our variable.
/*
* comments like this please
*/
+#if !defined(CONFIG_SYSVIPC) && !defined(CONFIG_POSIX_MQUEUE)
+struct ipc_namespace init_ipc_ns;
...
---
On Mon, 29 Oct 2018, chouryzhou(??) wrote:
+// If init_ipc_ns is not defined elsewhere,
+// we make a fake one here to put our variable.
/*
* comments like this please
*/
+#if !defined(CONFIG_SYSVIPC) && !defined(CONFIG_POSIX_MQUEUE)
+struct ipc_namespace init_ipc_ns;
...
---
The current logic is a bit convoluted. Lets simplify this with
a standard list_for_each_entry_safe() loop instead and just
break out after maxevents is reached.
While at it, remove an unnecessary indentation level in the loop
when there are in fact ready events.
Signed-off-by: Davidlohr Bueso
The current logic is a bit convoluted. Lets simplify this with
a standard list_for_each_entry_safe() loop instead and just
break out after maxevents is reached.
While at it, remove an unnecessary indentation level in the loop
when there are in fact ready events.
Signed-off-by: Davidlohr Bueso
show around a 20-30% increase in raw operations per second when
the box is fully occupied (incremental thread counts), and up to 15%
performance improvement with lower counts.
Passes ltp epoll related testcases. Please consider for v4.21/5.0.
Thanks!
Davidlohr Bueso (6):
fs/epoll: remove
s seen.
Similarly, by deleting the prediction, 3% throughput boost was
seen across incremental threads.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 101d46b81f64..347da3f4f5d3 100644
--
All callers pass the EP_MAX_NESTS constant already, so lets
simplify this a tad and get rid of the redundant parameter
for nested eventpolls.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/fs/eventpoll.c b/fs
Insted of just commenting how important it is, lets make
it more robust and add a lockdep_assert_held() call.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 347da3f4f5d3..6a0c2591e57e 100644
--- a/fs
to see partial values while the ready list is disabled.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 114 ++---
1 file changed, 60 insertions(+), 54 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 6a0c2591e57e..f6c023f085f6
show around a 20-30% increase in raw operations per second when
the box is fully occupied (incremental thread counts), and up to 15%
performance improvement with lower counts.
Passes ltp epoll related testcases. Please consider for v4.21/5.0.
Thanks!
Davidlohr Bueso (6):
fs/epoll: remove
s seen.
Similarly, by deleting the prediction, 3% throughput boost was
seen across incremental threads.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 101d46b81f64..347da3f4f5d3 100644
--
All callers pass the EP_MAX_NESTS constant already, so lets
simplify this a tad and get rid of the redundant parameter
for nested eventpolls.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/fs/eventpoll.c b/fs
Insted of just commenting how important it is, lets make
it more robust and add a lockdep_assert_held() call.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 347da3f4f5d3..6a0c2591e57e 100644
--- a/fs
to see partial values while the ready list is disabled.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 114 ++---
1 file changed, 60 insertions(+), 54 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index 6a0c2591e57e..f6c023f085f6
Upon timeout, we can just exit out of the loop, without
the cost of the changing the task's state smp_store_mb
call. Just exit out of the loop and be done - setting
the task state afterwards will be, of course, redundant.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 7 +--
1 file
Upon timeout, we can just exit out of the loop, without
the cost of the changing the task's state smp_store_mb
call. Just exit out of the loop and be done - setting
the task state afterwards will be, of course, redundant.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 7 +--
1 file
On Tue, 06 Nov 2018, Andrew Morton wrote:
It would be interesting to know precisely which stat fields the
database-which-shall-not-be-named is looking for. Then we could cook
up a very whizzy way of getting at the info.
The ctxt field, afaik. In any case they have been able to work around
On Tue, 06 Nov 2018, Andrew Morton wrote:
It would be interesting to know precisely which stat fields the
database-which-shall-not-be-named is looking for. Then we could cook
up a very whizzy way of getting at the info.
The ctxt field, afaik. In any case they have been able to work around
Mind this fixlet for using et/oneshot and the multiq option.
diff --git a/tools/perf/bench/epoll-wait.c b/tools/perf/bench/epoll-wait.c
index c4c5ef60feb4..4e4efc5cfe22 100644
--- a/tools/perf/bench/epoll-wait.c
+++ b/tools/perf/bench/epoll-wait.c
@@ -215,13 +215,13 @@ static void *workerfn(void
Mind this fixlet for using et/oneshot and the multiq option.
diff --git a/tools/perf/bench/epoll-wait.c b/tools/perf/bench/epoll-wait.c
index c4c5ef60feb4..4e4efc5cfe22 100644
--- a/tools/perf/bench/epoll-wait.c
+++ b/tools/perf/bench/epoll-wait.c
@@ -215,13 +215,13 @@ static void *workerfn(void
,
but the
result is the same.
Thanks!
Davidlohr Bueso (2):
perf-bench: Add epoll parallel epoll_wait benchmark
perf-bench: Add epoll_ctl(2) benchmark
tools/perf/Documentation/perf-bench.txt | 10 +
tools/perf/bench/Build | 3 +
tools/perf/bench/bench.h| 3
,
but the
result is the same.
Thanks!
Davidlohr Bueso (2):
perf-bench: Add epoll parallel epoll_wait benchmark
perf-bench: Add epoll_ctl(2) benchmark
tools/perf/Documentation/perf-bench.txt | 10 +
tools/perf/bench/Build | 3 +
tools/perf/bench/bench.h| 3
.
Signed-off-by: Davidlohr Bueso
---
tools/perf/Documentation/perf-bench.txt | 7 +
tools/perf/bench/Build | 2 +
tools/perf/bench/bench.h| 2 +
tools/perf/bench/epoll-wait.c | 536
tools/perf/builtin-bench.c
.
Signed-off-by: Davidlohr Bueso
---
tools/perf/Documentation/perf-bench.txt | 7 +
tools/perf/bench/Build | 2 +
tools/perf/bench/bench.h| 2 +
tools/perf/bench/epoll-wait.c | 536
tools/perf/builtin-bench.c
Benchmark the various operations allowed for epoll_ctl(2).
The idea is to concurrently stress a single epoll instance
doing add/mod/del operations.
Signed-off-by: Davidlohr Bueso
---
tools/perf/Documentation/perf-bench.txt | 3 +
tools/perf/bench/Build | 1 +
tools/perf
Benchmark the various operations allowed for epoll_ctl(2).
The idea is to concurrently stress a single epoll instance
doing add/mod/del operations.
Signed-off-by: Davidlohr Bueso
---
tools/perf/Documentation/perf-bench.txt | 3 +
tools/perf/bench/Build | 1 +
tools/perf
On Tue, 30 Oct 2018, Vito Caputo wrote:
If you create /proc/stat2 to omit interrupts, do we then create
/proc/stat3 to omit CPUs when just interrupts are of interest to the
application running on a 256-cpu machine?
Be real, this is a bogus argument. As mentioned, stat2 is named as such
On Tue, 30 Oct 2018, Vito Caputo wrote:
If you create /proc/stat2 to omit interrupts, do we then create
/proc/stat3 to omit CPUs when just interrupts are of interest to the
application running on a 256-cpu machine?
Be real, this is a bogus argument. As mentioned, stat2 is named as such
On Mon, 29 Oct 2018, Vito Caputo wrote:
I'm definitely not in favor of just adding another stat file that is the
same format as the existing one with the intrs zeroed out. It's a dirty
hack; fine for your local needs but too gross for upstream IMHO.
I suspect very few users of /proc/stat
On Mon, 29 Oct 2018, Vito Caputo wrote:
I'm definitely not in favor of just adding another stat file that is the
same format as the existing one with the intrs zeroed out. It's a dirty
hack; fine for your local needs but too gross for upstream IMHO.
I suspect very few users of /proc/stat
On Mon, 29 Oct 2018, Waiman Long wrote:
BTW, since you are making stat2 compatible with stat, will that be
easier from the user API perspective if we use a sysctl parameter to
turn on and off IRQs reporting for /proc/stat, for example?
For one /proc/stat is also common for debugging envs (ie:
On Mon, 29 Oct 2018, Waiman Long wrote:
BTW, since you are making stat2 compatible with stat, will that be
easier from the user API perspective if we use a sysctl parameter to
turn on and off IRQs reporting for /proc/stat, for example?
For one /proc/stat is also common for debugging envs (ie:
On Mon, 29 Oct 2018, Waiman Long wrote:
I am wondering if /proc/stat_noirqs will be a more descriptive name of
the intent of this new procfs file or we should just go with the more
generic stat2 name.
The reason why I went with '2' instead of a more rescriptive name
was that I think of the
On Mon, 29 Oct 2018, Waiman Long wrote:
I am wondering if /proc/stat_noirqs will be a more descriptive name of
the intent of this new procfs file or we should just go with the more
generic stat2 name.
The reason why I went with '2' instead of a more rescriptive name
was that I think of the
-- this was also previously
suggested by Waiman:
https://lore.kernel.org/lkml/1524166562-5644-1-git-send-email-long...@redhat.com/
Signed-off-by: Davidlohr Bueso
---
Documentation/filesystems/proc.txt | 12 +++---
fs/proc/stat.c | 45 --
2 files
-- this was also previously
suggested by Waiman:
https://lore.kernel.org/lkml/1524166562-5644-1-git-send-email-long...@redhat.com/
Signed-off-by: Davidlohr Bueso
---
Documentation/filesystems/proc.txt | 12 +++---
fs/proc/stat.c | 45 --
2 files
On Thu, 04 Oct 2018, Waiman Long wrote:
On 10/04/2018 03:16 AM, Jan Kara wrote:
On Wed 12-09-18 15:28:52, Waiman Long wrote:
From: Davidlohr Bueso
Instead of the current O(N) implementation, at the cost
of adding an atomic counter, we can convert the call to
an atomic_read(). The counter
On Thu, 04 Oct 2018, Waiman Long wrote:
On 10/04/2018 03:16 AM, Jan Kara wrote:
On Wed 12-09-18 15:28:52, Waiman Long wrote:
From: Davidlohr Bueso
Instead of the current O(N) implementation, at the cost
of adding an atomic counter, we can convert the call to
an atomic_read(). The counter
On Wed, 12 Sep 2018, Waiman Long wrote:
@@ -927,8 +921,6 @@ struct inode *new_inode(struct super_block *sb)
{
struct inode *inode;
- spin_lock_prefetch(>s_inode_list_lock);
I think we can get rid of the spin_lock_prefetch call altogether as this is the
only user left afaict.
On Wed, 12 Sep 2018, Waiman Long wrote:
@@ -927,8 +921,6 @@ struct inode *new_inode(struct super_block *sb)
{
struct inode *inode;
- spin_lock_prefetch(>s_inode_list_lock);
I think we can get rid of the spin_lock_prefetch call altogether as this is the
only user left afaict.
On Mon, 10 Sep 2018, Peter Zijlstra wrote:
[ RT has something along those lines, and I have half a patch that
starts doing that too, but I never found enough time to really work on
it :-( ]
But don't rt rwsems act pretty much like a regular mutex in that it only
allows readers to nest, not
On Mon, 10 Sep 2018, Peter Zijlstra wrote:
[ RT has something along those lines, and I have half a patch that
starts doing that too, but I never found enough time to really work on
it :-( ]
But don't rt rwsems act pretty much like a regular mutex in that it only
allows readers to nest, not
On Mon, 10 Sep 2018, Waiman Long wrote:
On 09/08/2018 12:13 AM, John Hubbard wrote:
Hi Daniel and all,
I'm interested in the first 3 of those 4 topics, so if it doesn't conflict with
HMM topics or
fix-gup-with-dma topics, I'd like to attend. GPUs generally need to access
large chunks of
On Mon, 10 Sep 2018, Waiman Long wrote:
On 09/08/2018 12:13 AM, John Hubbard wrote:
Hi Daniel and all,
I'm interested in the first 3 of those 4 topics, so if it doesn't conflict with
HMM topics or
fix-gup-with-dma topics, I'd like to attend. GPUs generally need to access
large chunks of
On Mon, 10 Sep 2018, Waiman Long wrote:
One major issue with a combined count/owner is that we may have to use
cmpxchg for reader lock which will certainly impact reader-heavy
workloads. I have also thought about ways to compress the task pointer
address so that it can use fewer bits and leave
On Mon, 10 Sep 2018, Waiman Long wrote:
One major issue with a combined count/owner is that we may have to use
cmpxchg for reader lock which will certainly impact reader-heavy
workloads. I have also thought about ways to compress the task pointer
address so that it can use fewer bits and leave
On Thu, 06 Sep 2018, Peter Zijlstra wrote:
On Fri, Jul 20, 2018 at 01:05:59PM -0700, Davidlohr Bueso wrote:
On Fri, 20 Jul 2018, Andrew Morton wrote:
>I'm surprised. Is spin_lock_irqsave() significantly more expensive
>than spin_lock_irq()? Relative to all the other stuff those fun
On Thu, 06 Sep 2018, Peter Zijlstra wrote:
On Fri, Jul 20, 2018 at 01:05:59PM -0700, Davidlohr Bueso wrote:
On Fri, 20 Jul 2018, Andrew Morton wrote:
>I'm surprised. Is spin_lock_irqsave() significantly more expensive
>than spin_lock_irq()? Relative to all the other stuff those fun
-by: Davidlohr Bueso
---
ipc/shm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ipc/shm.c b/ipc/shm.c
index b0eb3757ab89..4cd402e4cfeb 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -199,6 +199,7 @@ static inline struct shmid_kernel *shm_lock(struct
ipc_namespace *ns, int id
-by: Davidlohr Bueso
---
ipc/shm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ipc/shm.c b/ipc/shm.c
index b0eb3757ab89..4cd402e4cfeb 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -199,6 +199,7 @@ static inline struct shmid_kernel *shm_lock(struct
ipc_namespace *ns, int id
On Thu, 23 Aug 2018, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 296ba26b6681b6e07ed419b3004647167cb17f61 ("ipc: drop ipc_lock()")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
I suspect this is because that commit
On Thu, 23 Aug 2018, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 296ba26b6681b6e07ed419b3004647167cb17f61 ("ipc: drop ipc_lock()")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
I suspect this is because that commit
On Wed, 18 Jul 2018, Manfred Spraul wrote:
sma->use_global_lock is sometimes used with smp_load_acquire(),
sometimes without.
So far, I assumed that this is safe.
The same applies for nf_conntrack_locks_all, in nf_conntrack_all_lock()
So the netfilter code is safe wrt tearing as _all_
On Wed, 18 Jul 2018, Manfred Spraul wrote:
sma->use_global_lock is sometimes used with smp_load_acquire(),
sometimes without.
So far, I assumed that this is safe.
The same applies for nf_conntrack_locks_all, in nf_conntrack_all_lock()
So the netfilter code is safe wrt tearing as _all_
ct any mischief
before deadlocking.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index b5e43e11f1e3..88473e6271ef 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1746,11 +1
ct any mischief
before deadlocking.
Signed-off-by: Davidlohr Bueso
---
fs/eventpoll.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index b5e43e11f1e3..88473e6271ef 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -1746,11 +1
Instead of having each caller pass the rdllink explicitly,
just have ep_is_linked() pass it while the callers just need
the epi pointer. This helper is all about the rdllink, and
this change, furthermore, improves the function's self
documentation.
Signed-off-by: Davidlohr Bueso
---
fs
Instead of having each caller pass the rdllink explicitly,
just have ep_is_linked() pass it while the callers just need
the epi pointer. This helper is all about the rdllink, and
this change, furthermore, improves the function's self
documentation.
Signed-off-by: Davidlohr Bueso
---
fs
Hi,
Along the same lines than the previous work. Details are in patch 1.
Patch 2 is an add on while eyeballing the code. Similar to the previous
patches, this has survived ltp testcases and various workloads.
Thanks,
Davidlohr
Davidlohr Bueso (2):
fs/epoll: loosen irq safety in ep_poll()
fs
301 - 400 of 4799 matches
Mail list logo
