Paul Jackson wrote:
> Balbir wrote:
>> Thanks for the script. Would you like to contribute this script to
>> LTP for wider availability and testing?
>
> Sounds good - though I'm a tad lazy, and don't know how to contribute
> this to the LTP.
>
> You're welcome to contribute it yourself, if that's
Balbir wrote:
> Thanks for the script. Would you like to contribute this script to
> LTP for wider availability and testing?
Sounds good - though I'm a tad lazy, and don't know how to contribute
this to the LTP.
You're welcome to contribute it yourself, if that's easier for you,
or to point me in
Paul Jackson wrote:
> Balbir wrote:
>
> 1) Testing batch schedulers against cpusets:
>
> I doubt that the batch scheduler developers would be able to
> extract a cpuset test from their tests, or be able to share it if
> they did. Their tests tend to be large tests of batch scheduler
Balbir wrote:
> Would it be possible to extract those test cases and integrate them
> with a testing framework like LTP? Do you have any regression test
> suite for cpusets that can be made available publicly so that
> any changes to cpusets can be validated?
There are essentially two sorts of cpu
Paul Jackson wrote:
[[ I have bcc'd one or more batch scheduler experts on this post.
They will know who they are, and should be aware that they are
not listed in the public cc list of this message. - pj ]]
Balbir Singh, responding to Paul Menage's Container patch set on lkml, wr
[[ I have bcc'd one or more batch scheduler experts on this post.
They will know who they are, and should be aware that they are
not listed in the public cc list of this message. - pj ]]
Balbir Singh, responding to Paul Menage's Container patch set on lkml, wrote:
>
> > +*** notif
+static ssize_t container_read_uint(struct container *cont, struct cftype *cft,
+ struct file *file,
+ char __user *buf, size_t nbytes,
+ loff_t *ppos)
+{
+ char tmp[64];
+ u64 val = cft->
7 matches
Mail list logo
