Re: Question about SCHED_DEADLINE and sched_yield() usage
Hi Juri, On 08/11/2015 01:55 PM, Juri Lelli wrote: > As you are running a 3.14 kernel, you probably missed this fix > 5bfd126e80dc "sched/deadline: Fix sched_yield() behavior". Can > you please check? I stumbled over this commit but somehow managed to ignore it. Anyway, I upgraded to 4.1, now the application shows the expected behavior. >> As far as I understand, I have to call sched_yield() if the the >> execution time of one loop iteration is either not constant or unknown >> (both cases being very likely), because if I do not, a new loop >> iteration could be started if the time budget is not empty. >> > > It depends. The sched_yield() semantic for SCHED_DEADLINE might > be used to implement some sort of reclaiming mechanism (not > there yet) where you inform the scheduler that you are not going > to use the remaining runtime in this period; and the scheduler > could recycle this spare runtime for other tasks that are running > short of it. > > However, I'd say that in your case you can also live without it. > SCHED_DEADLINE can handle sporadic tasks, it depends on how you > implement your userspace loop I guess. If you just check the active > flag, and this flag is always set, you are right that you may > end up executing back to back, though; in which case it seems that yield > semantic could do the trick. Since samples are generated and the resulting curve looks like it was sampled with a constant frequency, I think that sched_yield() is to be used in this context. Before I used sched_yield(), I had to use some sleep statements, which made the sample frequency not deterministic and filled the CPU up. Now it seems to work pretty well. Congrats on the deadline scheduler - it is a great way to introduce some real-time capability - and thank you for your help. Best regards, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about SCHED_DEADLINE and sched_yield() usage
Hi Juri, On 08/11/2015 01:55 PM, Juri Lelli wrote: As you are running a 3.14 kernel, you probably missed this fix 5bfd126e80dc sched/deadline: Fix sched_yield() behavior. Can you please check? I stumbled over this commit but somehow managed to ignore it. Anyway, I upgraded to 4.1, now the application shows the expected behavior. As far as I understand, I have to call sched_yield() if the the execution time of one loop iteration is either not constant or unknown (both cases being very likely), because if I do not, a new loop iteration could be started if the time budget is not empty. It depends. The sched_yield() semantic for SCHED_DEADLINE might be used to implement some sort of reclaiming mechanism (not there yet) where you inform the scheduler that you are not going to use the remaining runtime in this period; and the scheduler could recycle this spare runtime for other tasks that are running short of it. However, I'd say that in your case you can also live without it. SCHED_DEADLINE can handle sporadic tasks, it depends on how you implement your userspace loop I guess. If you just check the active flag, and this flag is always set, you are right that you may end up executing back to back, though; in which case it seems that yield semantic could do the trick. Since samples are generated and the resulting curve looks like it was sampled with a constant frequency, I think that sched_yield() is to be used in this context. Before I used sched_yield(), I had to use some sleep statements, which made the sample frequency not deterministic and filled the CPU up. Now it seems to work pretty well. Congrats on the deadline scheduler - it is a great way to introduce some real-time capability - and thank you for your help. Best regards, Michael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question about SCHED_DEADLINE and sched_yield() usage
Hi all,
I connected two analog-to-digital converters to a BeagleBoneBlack (with
kernel version 3.14.33-ti-r51.2) and tried to use the deadline scheduler
to get samples at a constant rate. In my C++/Qt application the ADCs are
represented by a class which is derived from QThread. The run() method
is basically:
run()
{
unsigned int flags;
struct sched_attr attr;
attr.sched_policy = SCHED_DEADLINE;
attr.sched_runtime = 600 * 1000;
attr.sched_deadline = 1250 * 1000;
attr.sched_period = 1250 * 1000;
sched_setattr(0, , flags);
while (active) {
/* code that gets a sample from adc, takes around 500 ms */
sched_yield();
}
}
to get samples at a rate of 800 Hz. However, once sched_yield() is
called, the threads do not seem to be scheduled again (no samples are
acquired and when the application shuts down the threads remain as zombies).
As far as I understand, I have to call sched_yield() if the the
execution time of one loop iteration is either not constant or unknown
(both cases being very likely), because if I do not, a new loop
iteration could be started if the time budget is not empty.
Have I missed something? Any ideas or alternative approaches are welcome!
Thanks a lot in advance!
Best regards, Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Question about SCHED_DEADLINE and sched_yield() usage
Hi all,
I connected two analog-to-digital converters to a BeagleBoneBlack (with
kernel version 3.14.33-ti-r51.2) and tried to use the deadline scheduler
to get samples at a constant rate. In my C++/Qt application the ADCs are
represented by a class which is derived from QThread. The run() method
is basically:
run()
{
unsigned int flags;
struct sched_attr attr;
attr.sched_policy = SCHED_DEADLINE;
attr.sched_runtime = 600 * 1000;
attr.sched_deadline = 1250 * 1000;
attr.sched_period = 1250 * 1000;
sched_setattr(0, attr, flags);
while (active) {
/* code that gets a sample from adc, takes around 500 ms */
sched_yield();
}
}
to get samples at a rate of 800 Hz. However, once sched_yield() is
called, the threads do not seem to be scheduled again (no samples are
acquired and when the application shuts down the threads remain as zombies).
As far as I understand, I have to call sched_yield() if the the
execution time of one loop iteration is either not constant or unknown
(both cases being very likely), because if I do not, a new loop
iteration could be started if the time budget is not empty.
Have I missed something? Any ideas or alternative approaches are welcome!
Thanks a lot in advance!
Best regards, Michael
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rtnetlink: Call nlmsg_parse() with correct header length
Signed-off-by: Michael Riesch
Cc: "David S. Miller"
Cc: Greg Kroah-Hartman
Cc: Jiri Benc
Cc: "Theodore Ts'o"
Cc: linux-kernel@vger.kernel.org
---
Habidere,
I encountered a netlink kernel warning when running avahi 0.6.31 on my system
with kernel v3.4.35 (it appears several times):
netlink: 12 bytes leftover after parsing attributes.
Searching the web showed that commit "115c9b81928360d769a76c632bae62d15206a94a
rtnetlink: Fix problem with buffer allocation" introduced this behaviour[1].
Now I - knowing nothing about netlink whatsoever - assume that the nlmsg_parse
function is called with the wrong header length. In user space the request
message consists out of the message header (struct nlmsghdr, 16 bytes) and an
ifinfomsg (struct ifinfomsg, 16 bytes). After that, request attributes could
follow. nlmsg_parse checks for this attributes after a given header length. In
rtnl_get_link() this header length is sizeof(struct ifinfomsg), but in
rtnl_calcit() as well as in rntl_dump_ifinfo() the header length is
sizeof(struct rtgenmsg), which is 1 byte.
With this patch I got rid of these warnings. However, I do not know whether
this is the correct solution, so I am looking forward to your comments.
Regards, Michael
[1] http://lists.infradead.org/pipermail/libnl/2012-April/000515.html
net/core/rtnetlink.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 900fc61..ebf6ace 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1065,7 +1065,7 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct
netlink_callback *cb)
rcu_read_lock();
cb->seq = net->dev_base_seq;
- if (nlmsg_parse(cb->nlh, sizeof(struct rtgenmsg), tb, IFLA_MAX,
+ if (nlmsg_parse(cb->nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
ifla_policy) >= 0) {
if (tb[IFLA_EXT_MASK])
@@ -1909,7 +1909,7 @@ static u16 rtnl_calcit(struct sk_buff *skb, struct
nlmsghdr *nlh)
u32 ext_filter_mask = 0;
u16 min_ifinfo_dump_size = 0;
- if (nlmsg_parse(nlh, sizeof(struct rtgenmsg), tb, IFLA_MAX,
+ if (nlmsg_parse(nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
ifla_policy) >= 0) {
if (tb[IFLA_EXT_MASK])
ext_filter_mask = nla_get_u32(tb[IFLA_EXT_MASK]);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rtnetlink: Call nlmsg_parse() with correct header length
Signed-off-by: Michael Riesch michael.rie...@omicron.at
Cc: David S. Miller da...@davemloft.net
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Benc jb...@redhat.com
Cc: Theodore Ts'o ty...@mit.edu
Cc: linux-kernel@vger.kernel.org
---
Habidere,
I encountered a netlink kernel warning when running avahi 0.6.31 on my system
with kernel v3.4.35 (it appears several times):
netlink: 12 bytes leftover after parsing attributes.
Searching the web showed that commit 115c9b81928360d769a76c632bae62d15206a94a
rtnetlink: Fix problem with buffer allocation introduced this behaviour[1].
Now I - knowing nothing about netlink whatsoever - assume that the nlmsg_parse
function is called with the wrong header length. In user space the request
message consists out of the message header (struct nlmsghdr, 16 bytes) and an
ifinfomsg (struct ifinfomsg, 16 bytes). After that, request attributes could
follow. nlmsg_parse checks for this attributes after a given header length. In
rtnl_get_link() this header length is sizeof(struct ifinfomsg), but in
rtnl_calcit() as well as in rntl_dump_ifinfo() the header length is
sizeof(struct rtgenmsg), which is 1 byte.
With this patch I got rid of these warnings. However, I do not know whether
this is the correct solution, so I am looking forward to your comments.
Regards, Michael
[1] http://lists.infradead.org/pipermail/libnl/2012-April/000515.html
net/core/rtnetlink.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 900fc61..ebf6ace 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1065,7 +1065,7 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct
netlink_callback *cb)
rcu_read_lock();
cb-seq = net-dev_base_seq;
- if (nlmsg_parse(cb-nlh, sizeof(struct rtgenmsg), tb, IFLA_MAX,
+ if (nlmsg_parse(cb-nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
ifla_policy) = 0) {
if (tb[IFLA_EXT_MASK])
@@ -1909,7 +1909,7 @@ static u16 rtnl_calcit(struct sk_buff *skb, struct
nlmsghdr *nlh)
u32 ext_filter_mask = 0;
u16 min_ifinfo_dump_size = 0;
- if (nlmsg_parse(nlh, sizeof(struct rtgenmsg), tb, IFLA_MAX,
+ if (nlmsg_parse(nlh, sizeof(struct ifinfomsg), tb, IFLA_MAX,
ifla_policy) = 0) {
if (tb[IFLA_EXT_MASK])
ext_filter_mask = nla_get_u32(tb[IFLA_EXT_MASK]);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
