* 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 r
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 *own
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 t
* 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 (!sched_feat(OW
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, speci
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 t
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 simultan
7 matches
Mail list logo