lkml.org 
[lkml]   [2013]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 02/14] sched: add extended scheduling interface.
    On Thu,  7 Nov 2013 14:43:36 +0100
    Juri Lelli <juri.lelli@gmail.com> wrote:


    > + * This is reflected by the actual fields of the sched_param2 structure:
    > + *
    > + * @sched_priority task's priority (might still be useful)
    > + * @sched_deadline representative of the task's deadline
    > + * @sched_runtime representative of the task's runtime
    > + * @sched_period representative of the task's period
    > + * @sched_flags for customizing the scheduler behaviour
    > + *
    > + * Given this task model, there are a multiplicity of scheduling algorithms
    > + * and policies, that can be used to ensure all the tasks will make their
    > + * timing constraints.
    > + *
    > + * @__unused padding to allow future expansion without ABI issues
    > + */
    > +struct sched_param2 {
    > + int sched_priority;
    > + unsigned int sched_flags;

    I'm just thinking, if we are creating a new structure, and this
    structure already contains u64 elements, why not make sched_flags u64
    too? We are now just limiting the total number of possible flags to 32.
    I'm not sure how many flags will be needed in the future, maybe 32 is
    good enough, but just something to think about.

    Of course you can argue that the int sched_flags matches the int
    sched_priority leaving out any holes in the structure, which is a
    legitimate argument.

    > + u64 sched_runtime;
    > + u64 sched_deadline;
    > + u64 sched_period;
    > +
    > + u64 __unused[12];

    And in the future, we could use one of these __unused[12] as a
    sched_flags2;

    I'm not saying we should make it u64, just wanted to make sure we are
    fine with it as 32 for now.

    -- Steve



    > +};
    > +


    \
     
     \ /
      Last update: 2013-11-12 19:01    [W:2.188 / U:0.160 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site