Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-17 Thread Alex Shi
On 06/07/2013 03:29 PM, Alex Shi wrote: > Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are > smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64 > vaiables to describe them. unsigned long is more efficient and convenience. > update with a a bit clean up in

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-17 Thread Alex Shi
On 06/17/2013 05:49 PM, Paul Turner wrote: >>> >> Hi Alex, >>> >> >>> >> I just want to point out that we can't have more than 48388 tasks with >>> >> highest priority on a runqueue with an unsigned long on a 32 bits >>> >> system. I don't know if we can reach such kind of limit on a 32bits >>>

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-17 Thread Alex Shi
On 06/17/2013 05:54 PM, Vincent Guittot wrote: >> > So, usually the limited task number in Linux is often far lower this >> > number: $ulimit -u. >> > >> > Anyway, at least, the runnable_load_avg is smaller then load.weight. if >> > load.weight can use long type, runablle_load_avg is no reason

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-17 Thread Vincent Guittot
On 8 June 2013 04:18, Alex Shi wrote: > On 06/07/2013 05:07 PM, Vincent Guittot wrote: >> On 7 June 2013 09:29, Alex Shi wrote: >>> > Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are >>> > smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64 >>> > vaiables

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-17 Thread Paul Turner
On Fri, Jun 7, 2013 at 7:18 PM, Alex Shi wrote: > On 06/07/2013 05:07 PM, Vincent Guittot wrote: >> On 7 June 2013 09:29, Alex Shi wrote: >>> > Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are >>> > smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64 >>> >

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-17 Thread Paul Turner
On Fri, Jun 7, 2013 at 7:18 PM, Alex Shi alex@intel.com wrote: On 06/07/2013 05:07 PM, Vincent Guittot wrote: On 7 June 2013 09:29, Alex Shi alex@intel.com wrote: Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are smaller than 'unsigned long' cfs_rq-load.weight.

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-17 Thread Vincent Guittot
On 8 June 2013 04:18, Alex Shi alex@intel.com wrote: On 06/07/2013 05:07 PM, Vincent Guittot wrote: On 7 June 2013 09:29, Alex Shi alex@intel.com wrote: Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are smaller than 'unsigned long' cfs_rq-load.weight. We don't

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-17 Thread Alex Shi
On 06/17/2013 05:54 PM, Vincent Guittot wrote: So, usually the limited task number in Linux is often far lower this number: $ulimit -u. Anyway, at least, the runnable_load_avg is smaller then load.weight. if load.weight can use long type, runablle_load_avg is no reason can't. Alex,

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-17 Thread Alex Shi
On 06/17/2013 05:49 PM, Paul Turner wrote: Hi Alex, I just want to point out that we can't have more than 48388 tasks with highest priority on a runqueue with an unsigned long on a 32 bits system. I don't know if we can reach such kind of limit on a 32bits machine ? For sure, not on

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-17 Thread Alex Shi
On 06/07/2013 03:29 PM, Alex Shi wrote: Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are smaller than 'unsigned long' cfs_rq-load.weight. We don't need u64 vaiables to describe them. unsigned long is more efficient and convenience. update with a a bit clean up in

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-07 Thread Alex Shi
On 06/07/2013 05:07 PM, Vincent Guittot wrote: > On 7 June 2013 09:29, Alex Shi wrote: >> > Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are >> > smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64 >> > vaiables to describe them. unsigned long is more

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-07 Thread Vincent Guittot
On 7 June 2013 09:29, Alex Shi wrote: > Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are > smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64 > vaiables to describe them. unsigned long is more efficient and convenience. > Hi Alex, I just want to point

[RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-07 Thread Alex Shi
Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are smaller than 'unsigned long' cfs_rq->load.weight. We don't need u64 vaiables to describe them. unsigned long is more efficient and convenience. Signed-off-by: Alex Shi --- kernel/sched/debug.c | 4 ++--

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-07 Thread Alex Shi
On 06/07/2013 05:07 PM, Vincent Guittot wrote: On 7 June 2013 09:29, Alex Shi alex@intel.com wrote: Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are smaller than 'unsigned long' cfs_rq-load.weight. We don't need u64 vaiables to describe them. unsigned long is

[RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-07 Thread Alex Shi
Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are smaller than 'unsigned long' cfs_rq-load.weight. We don't need u64 vaiables to describe them. unsigned long is more efficient and convenience. Signed-off-by: Alex Shi alex@intel.com --- kernel/sched/debug.c | 4 ++--

Re: [RFC patch 1/4] sched: change cfs_rq load avg to unsigned long

2013-06-07 Thread Vincent Guittot
On 7 June 2013 09:29, Alex Shi alex@intel.com wrote: Since the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are smaller than 'unsigned long' cfs_rq-load.weight. We don't need u64 vaiables to describe them. unsigned long is more efficient and convenience. Hi Alex, I just