* Waiman Long wrote:
> > I'd suggest a preparatory patch that gets rid of that flag and moves these
> > two
> > functions from sched/core.c to mutex.c where they belong.
> >
> > This will also allow the removal of the mutex prototypes from sched.h.
>
> Yes, I can certainly prepare a patch to
* Waiman Long waiman.l...@hp.com wrote:
I'd suggest a preparatory patch that gets rid of that flag and moves these
two
functions from sched/core.c to mutex.c where they belong.
This will also allow the removal of the mutex prototypes from sched.h.
Yes, I can certainly prepare a
On 04/16/2013 05:10 AM, Ingo Molnar wrote:
* Waiman Long wrote:
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3021,9 +3021,6 @@ static inline bool owner_running(struct mutex *lock,
struct task_struct *owner)
*/
int mutex_spin_on_owner(struct mutex *lock, struct task_struct
On 04/16/2013 12:24 AM, Davidlohr Bueso wrote:
On Mon, 2013-04-15 at 10:37 -0400, Waiman Long wrote:
[...]
+typedef struct mspin_node {
+ struct mspin_node *next;
+ intlocked; /* 1 if lock acquired */
+} mspin_node_t;
+
+typedef mspin_node_t *mspin_lock_t;
I
* Waiman Long wrote:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3021,9 +3021,6 @@ static inline bool owner_running(struct mutex *lock,
> struct task_struct *owner)
> */
> int mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner)
> {
> - if
* Waiman Long waiman.l...@hp.com wrote:
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3021,9 +3021,6 @@ static inline bool owner_running(struct mutex *lock,
struct task_struct *owner)
*/
int mutex_spin_on_owner(struct mutex *lock, struct task_struct *owner)
{
- if
On 04/16/2013 12:24 AM, Davidlohr Bueso wrote:
On Mon, 2013-04-15 at 10:37 -0400, Waiman Long wrote:
[...]
+typedef struct mspin_node {
+ struct mspin_node *next;
+ intlocked; /* 1 if lock acquired */
+} mspin_node_t;
+
+typedef mspin_node_t *mspin_lock_t;
I
On 04/16/2013 05:10 AM, Ingo Molnar wrote:
* Waiman Longwaiman.l...@hp.com wrote:
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3021,9 +3021,6 @@ static inline bool owner_running(struct mutex *lock,
struct task_struct *owner)
*/
int mutex_spin_on_owner(struct mutex *lock,
On Mon, 2013-04-15 at 10:37 -0400, Waiman Long wrote:
[...]
> +typedef struct mspin_node {
> + struct mspin_node *next;
> + intlocked; /* 1 if lock acquired */
> +} mspin_node_t;
> +
> +typedef mspin_node_t *mspin_lock_t;
I think we could do without the typedefs,
On 04/15/2013 10:37 AM, Waiman Long wrote:
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option turned
on) allow multiple tasks to spin on a single mutex concurrently. A
potential problem with the current approach is that when the mutex
becomes available, all the spinning tasks will
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option turned
on) allow multiple tasks to spin on a single mutex concurrently. A
potential problem with the current approach is that when the mutex
becomes available, all the spinning tasks will try to acquire the
mutex more or less
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option turned
on) allow multiple tasks to spin on a single mutex concurrently. A
potential problem with the current approach is that when the mutex
becomes available, all the spinning tasks will try to acquire the
mutex more or less
On 04/15/2013 10:37 AM, Waiman Long wrote:
The current mutex spinning code (with MUTEX_SPIN_ON_OWNER option turned
on) allow multiple tasks to spin on a single mutex concurrently. A
potential problem with the current approach is that when the mutex
becomes available, all the spinning tasks will
On Mon, 2013-04-15 at 10:37 -0400, Waiman Long wrote:
[...]
+typedef struct mspin_node {
+ struct mspin_node *next;
+ intlocked; /* 1 if lock acquired */
+} mspin_node_t;
+
+typedef mspin_node_t *mspin_lock_t;
I think we could do without the typedefs, specially
14 matches
Mail list logo
