[LTP] [PATCH] cgroups/cpuset_base_ops: 6 is valid value for sched_relax_domain_level

[LTP] [PATCH] cgroups/cpuset_base_ops: 6 is valid value for sched_relax_domain_level

[Jan Stancek]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]


commit 01a08546af311c065f34727787dd0cc8dc0c216f in linux
kernel tree introduced SD_LV_BOOK, which made value "6" valid.

It is questionable if this test should be in at all,
the sched domain mapping can be completely overridden by
the architecture-specific code.

Anyway, a quick solution for now is to skip testing value "6",
as it may work on newer kernels.

Signed-off-by: Jan Stancek <jstancek@redhat.com>
---
 .../cpuset_base_ops_testset.sh                     |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-cgroups-cpuset_base_ops-6-is-valid-value-for-sched_r.patch --]
[-- Type: text/x-patch; name=0001-cgroups-cpuset_base_ops-6-is-valid-value-for-sched_r.patch, Size: 719 bytes --]

diff --git a/testcases/kernel/controllers/cpuset/cpuset_base_ops_test/cpuset_base_ops_testset.sh b/testcases/kernel/controllers/cpuset/cpuset_base_ops_test/cpuset_base_ops_testset.sh
index 2b1016e..da1f6da 100755
--- a/testcases/kernel/controllers/cpuset/cpuset_base_ops_test/cpuset_base_ops_testset.sh
+++ b/testcases/kernel/controllers/cpuset/cpuset_base_ops_test/cpuset_base_ops_testset.sh
@@ -190,12 +190,13 @@ test_domain()
 		3	3
 		4	4
 		5	5
-		6	WRITE_ERROR
+		7	WRITE_ERROR
 		-1	-1
 		-2	WRITE_ERROR
 		A	WRITE_ERROR
 	EOF
 	# while read domain_level result
+	# changed limit to 7, as 6 might succeed, see SD_LV_MAX in include/linux/sched.h
 }
 
 # attach_task_test <cpus> <mems> <expect>

[-- Attachment #3: Type: text/plain, Size: 438 bytes --]

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev

[-- Attachment #4: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] cgroups/cpuset_base_ops: 6 is valid value for sched_relax_domain_level

[Garrett Cooper]

On Tue, Apr 19, 2011 at 6:21 AM, Jan Stancek <jstancek@redhat.com> wrote:
>
> commit 01a08546af311c065f34727787dd0cc8dc0c216f in linux
> kernel tree introduced SD_LV_BOOK, which made value "6" valid.
>
> It is questionable if this test should be in at all,
> the sched domain mapping can be completely overridden by
> the architecture-specific code.
>
> Anyway, a quick solution for now is to skip testing value "6",
> as it may work on newer kernels.

This may be quick and dirty, but now it changes boundary conditions
for the testcase.

Is there a way where you could quickly come up with a series of
autoconf driven/Makefile generated means for driving this testcase? It
seems like that would be the most ideal solution to this problem as
that would preserve the boundary condition with older kernels.

Thanks!
-Garrett

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] cgroups/cpuset_base_ops: 6 is valid value for sched_relax_domain_level

[Jan Stancek]

----- Original Message -----
> From: "Garrett Cooper" <yanegomi@gmail.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: ltp-list@lists.sourceforge.net
> Sent: Tuesday, April 19, 2011 6:16:45 PM
> Subject: Re: [LTP] [PATCH] cgroups/cpuset_base_ops: 6 is valid value for sched_relax_domain_level
> On Tue, Apr 19, 2011 at 6:21 AM, Jan Stancek <jstancek@redhat.com>
> wrote:
> >
> > commit 01a08546af311c065f34727787dd0cc8dc0c216f in linux
> > kernel tree introduced SD_LV_BOOK, which made value "6" valid.
> >
> > It is questionable if this test should be in at all,
> > the sched domain mapping can be completely overridden by
> > the architecture-specific code.
> >
> > Anyway, a quick solution for now is to skip testing value "6",
> > as it may work on newer kernels.
> 
> This may be quick and dirty, but now it changes boundary conditions
> for the testcase.
> 
> Is there a way where you could quickly come up with a series of
> autoconf driven/Makefile generated means for driving this testcase? It
> seems like that would be the most ideal solution to this problem as
> that would preserve the boundary condition with older kernels.

I don't see any way to find out range from user-space.
Even with CONFIG_SCHED_DEBUG, sched_domain->level isn't exported to /proc.

I think whole test isn't much useful, as it is very unlikely
you would have all scheduling domains available:
http://lxr.linux.no/#linux+v2.6.38/kernel/sched.c#L6995

Quoting Peter Zijlstra:
"More like, use sched_debug boot parameter and see your dmesg output.
I've recently merged a patch that makes the whole level thing completely
dynamic, there's no more fixed levels."

At the moment, I'm out of ideas how to find out acceptable range.

> 
> Thanks!
> -Garrett

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] cgroups/cpuset_base_ops: 6 is valid value for sched_relax_domain_level

[Garrett Cooper]

On Tue, Apr 19, 2011 at 10:32 AM, Jan Stancek <jstancek@redhat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Garrett Cooper" <yanegomi@gmail.com>
>> To: "Jan Stancek" <jstancek@redhat.com>
>> Cc: ltp-list@lists.sourceforge.net
>> Sent: Tuesday, April 19, 2011 6:16:45 PM
>> Subject: Re: [LTP] [PATCH] cgroups/cpuset_base_ops: 6 is valid value for sched_relax_domain_level
>> On Tue, Apr 19, 2011 at 6:21 AM, Jan Stancek <jstancek@redhat.com>
>> wrote:
>> >
>> > commit 01a08546af311c065f34727787dd0cc8dc0c216f in linux
>> > kernel tree introduced SD_LV_BOOK, which made value "6" valid.
>> >
>> > It is questionable if this test should be in at all,
>> > the sched domain mapping can be completely overridden by
>> > the architecture-specific code.
>> >
>> > Anyway, a quick solution for now is to skip testing value "6",
>> > as it may work on newer kernels.
>>
>> This may be quick and dirty, but now it changes boundary conditions
>> for the testcase.
>>
>> Is there a way where you could quickly come up with a series of
>> autoconf driven/Makefile generated means for driving this testcase? It
>> seems like that would be the most ideal solution to this problem as
>> that would preserve the boundary condition with older kernels.
>
> I don't see any way to find out range from user-space.
> Even with CONFIG_SCHED_DEBUG, sched_domain->level isn't exported to /proc.
>
> I think whole test isn't much useful, as it is very unlikely
> you would have all scheduling domains available:
> http://lxr.linux.no/#linux+v2.6.38/kernel/sched.c#L6995
>
> Quoting Peter Zijlstra:
> "More like, use sched_debug boot parameter and see your dmesg output.
> I've recently merged a patch that makes the whole level thing completely
> dynamic, there's no more fixed levels."
>
> At the moment, I'm out of ideas how to find out acceptable range.

    Just make the test only run on kernels without that particular
functionality. I assume that's possible in some way, or was the author
not nice enough to do that (I have to remember that this is Linux and
sane versioning with kernel/userland sources, etc aren't commonplace
like BSD)?
Thanks,
-Garrett

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] cgroups/cpuset_base_ops: 6 is valid value for sched_relax_domain_level

[Cyril Hrubis]

Hi!
> > I don't see any way to find out range from user-space.
> > Even with CONFIG_SCHED_DEBUG, sched_domain->level isn't exported to /proc.
> >
> > I think whole test isn't much useful, as it is very unlikely
> > you would have all scheduling domains available:
> > http://lxr.linux.no/#linux+v2.6.38/kernel/sched.c#L6995
> >
> > Quoting Peter Zijlstra:
> > "More like, use sched_debug boot parameter and see your dmesg output.
> > I've recently merged a patch that makes the whole level thing completely
> > dynamic, there's no more fixed levels."
> >
> > At the moment, I'm out of ideas how to find out acceptable range.
> 
>     Just make the test only run on kernels without that particular
> functionality. I assume that's possible in some way, or was the author
> not nice enough to do that (I have to remember that this is Linux and
> sane versioning with kernel/userland sources, etc aren't commonplace
> like BSD)?

It's more complicated than that. There are several kernel constants that
are considered internal, these may be changed by config knobs
architecture or particular commit. And sometimes there is no way to get
these from running kernel (as it doesn't make sence to get them until
you are trying to test that particular part of the kernel works some
way).

Even more the kernel is every changing codebase, so what was influenced
by constant may not exist anymore (and the interface for userspace
don't need to be changed at all) just internal implementation.

And if that's the case. I would rather get rid of test that rely on some
kernel internals and speculated behaviour, rather than spending eternity
patching it for each release.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] [PATCH] cgroups/cpuset_base_ops: 6 is valid value for sched_relax_domain_level

[Cyril Hrubis]

Hi!
> >>     Just make the test only run on kernels without that particular
> >> functionality. I assume that's possible in some way, or was the author
> >> not nice enough to do that (I have to remember that this is Linux and
> >> sane versioning with kernel/userland sources, etc aren't commonplace
> >> like BSD)?
> >
> > It's more complicated than that. There are several kernel constants that
> > are considered internal, these may be changed by config knobs
> > architecture or particular commit. And sometimes there is no way to get
> > these from running kernel (as it doesn't make sence to get them until
> > you are trying to test that particular part of the kernel works some
> > way).
> >
> > Even more the kernel is every changing codebase, so what was influenced
> > by constant may not exist anymore (and the interface for userspace
> > don't need to be changed at all) just internal implementation.
> >
> > And if that's the case. I would rather get rid of test that rely on some
> > kernel internals and speculated behaviour, rather than spending eternity
> > patching it for each release.
> 
>     Fair enough. It would be nice if there was some way to expose this
> information via debug /proc (or better -- /sys) entries though.
> Otherwise doing graybox / whitebox testing of the Linux kernel is
> impossible.
> Thanks,

Well yes, the problem here is that linux kernel wasn't really made to be
testeded (and that is true even for POSIX at least partially) we need
probably to do some talks to let the kernel people know that if they
want good testsuites, they need to lend a helping hand.

-- 
Cyril Hrubis
chrubis@suse.cz

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list