Skip to content

Commit

Permalink
Revert "softirq: Let ksoftirqd do its job"
Browse files Browse the repository at this point in the history 
This reverts commit 4cd13c2.
  • Loading branch information
@popcornmix
popcornmix committed Feb 9, 2018
1 parent 8c7e717 commit 0d118e3
Showing 1 changed file with 1 addition and 15 deletions.
16 changes: 1 addition & 15 deletions kernel/softirq.c
View file
Expand Up @@ -77,17 +77,6 @@ static void wakeup_softirqd(void)
wake_up_process(tsk);
}

/*
* If ksoftirqd is scheduled, we do not want to process pending softirqs
* right now. Let ksoftirqd handle this at its own rate, to get fairness.
*/
static bool ksoftirqd_running(void)
{
struct task_struct *tsk = __this_cpu_read(ksoftirqd);

return tsk && (tsk->state == TASK_RUNNING);
}

/*
* preempt_count and SOFTIRQ_OFFSET usage:
* - preempt_count is changed by SOFTIRQ_OFFSET on entering or leaving
Expand Down Expand Up @@ -324,7 +313,7 @@ asmlinkage __visible void do_softirq(void)

pending = local_softirq_pending();

if (pending && !ksoftirqd_running())
if (pending)
do_softirq_own_stack();

local_irq_restore(flags);
Expand All @@ -351,9 +340,6 @@ void irq_enter(void)

static inline void invoke_softirq(void)
{
if (ksoftirqd_running())
return;

if (!force_irqthreads) {
#ifdef CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK
/*
Expand Down

19 comments on commit 0d118e3

@guysoft
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey,
So this commit needs to be reverted if one wants to build a realtime kernel.
Can you explain if this breaks something critical?

@pelwell
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That commit is already reverted (removed, actually) in the rpi-4.14.y-rt kernel branch.

@guysoft
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pelwell Cool! Are you guys maintaining rpi-4.14.y-rt? Or are you just playing with it?
I am the maintainer of https://github.com/guysoft/RealtimePi .
Should I just I maintain my patches there? Or do you want people to use this branch?

@pelwell
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are essentially just hosting it for the benefit of our users. @TiejunChina has created it and is maintaining it with our blessing.

@pelwell
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sure he would welcome some more interest and help - it makes sense for the RPi RT enthusiasts to work together.

@guysoft
Copy link

@guysoft guysoft commented on 0d118e3 Apr 23, 2018 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Posted about it here too:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=206750&p=1306688#p1306688
(but personally prefer github to talks, dono why, they just seem more productive).

Sounds like you guys have the kernel and I have the the nightly build system. Would love to have some talk and get this as a steady release which is coordinated. Just say when.

@pelwell
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds like the best way forward would be for you to switch to building the rpi-4.14.y-rt branch, feeding back any improvements you have.

The branch model for the -rt branch(es) mirrors the way the rpi- branches track upstream. Upstream (Linux) patches are always merged, not rebased. During the bring-up period for a new kernel version downstream patches can be rebased and squashed, but once it goes live we only use fast-forward commits, merging in upstream commits incrementally as they are released.

For the -rt branch, "upstream" is the appropriate rpi- branch, so rpi- commits (and the Linux commits it includes) are always merged, not rebased.

@guysoft
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I pushed this branch (which basically deletes all the locally maintained patches). Waiting for the current new kernel build to finish so I have a nightly build. Then will try to build the rpi-4.14.y-rt branch.
They current build system upside is that its super easy to maintain, but the down is that it can take several hours to build both kernels. Still, since I was never in a hurry I didn't mind waiting.

But would really want to hear what @TiejunChina has to say. I don't want to switch systems without having everyone on the same page.

@TiejunChina
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@guysoft Welcome to contribute -rt branch. @pelwell But actually I didn't revert this since I always think this commit is in standard rpi branch so I keep this in -rt as well. But yes, to be honest, I really don't understand why we have this in standard branch. Unfortunately, this commit didn't provide a long log to explain something. So if you think this doesn't make sense, I would say we can remove this commit from standard branch directly.

@guysoft
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TiejunChina At the moment I am maintaining a list of patches that are applied before and after applying the RT patches to a specific commit to the raspberrypi kernel.
Attaching graphic to make it easy to understand:
screenshot_20180424_111728

It makes it easy for me to understand what went in, what didn't against the master of raspberrypi/linux branch.

the usdb-dwc_otg patch is taken from here. And is stored here

The questions is - should I move to what you are doing and expect it to be maintained?
I can contribute, but not maintain your method.

@TiejunChina
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@guysoft

Basically, there are two stages. Here we are talking about rpi-4.14.y vs rpi-4.14.y-rt.

Stage 0: This means rpi-4.14.y was not frozen. At this stage, I applied -rt patches onto the mainline base branch of rpi-4.14.y, and then rebase all patches specific to rpi. If we can get new version of -rt patches, we repeat that step again to make sure we have the latest -rt patches. This our rpi-4.14.y-rt in the beginning.

Stage 1: Once rpi-4.14.y is released, we don't rebase anything. Instead, essentially we only apply -rt delta stuff between last -rt version patches existed in rpi-4.14.y-rt and new -rt version patches. At the same time, we merge rpi-4.14.y regularly and apply any fix specific to -rt.

the usdb-dwc_otg patch was already in rpi-4.14.y-rt in the very beginning.

@guysoft
Copy link

@guysoft guysoft commented on 0d118e3 Apr 24, 2018 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok,

  • the thing is that that method might create unresolvable conflicts that might not work without the knowledge of what happened in the history.
  • I am not sure what happens when a new changes roles in from raspberrypi/linux and they break something.

So I am not really sure which method is better.
Will confess am tempted to just use rpi-4.14.y-rt because it means less maintenance on my end.

Will RealtimePi benefit you if it uses rpi-4.14.y-rt?
It would mean users can try out and report bugs directly to both of us.

@TiejunChina
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maintainer should play this role of rebasing this with fixing any conflict.

I think -rt is like sort of another kernel type. Ideally, -rt = mainline Linux base + rt patches + all BSP parches specific to different platform + Any fix to conflict between standard and rt + -rt fix specific to BSP.

What do you want to play here?

@guysoft
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to play here is disro builder. Aka each time there is a new raspbian release or change in the kernel, release an image people can flash.
So you have raspbian, and you have realtime raspbian that was built and tested.

@guysoft
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See: http://unofficialpi.org/Distros/RealtimePi/nightly/

@guysoft
Copy link

@guysoft guysoft commented on 0d118e3 Jun 28, 2018 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok
Nightly builds of 0.4.0 are pointed to the rpi-4.14.y-rt branch.
Also since the talks here I added an option to export the kernel. So I am also shipping a .tar.gz that includes all you need to install the kernel on a running raspbian distro. Or better yet - write a script that lets you switch between realtime and non-realtime.
So you get:
http://unofficialpi.org/Distros/RealtimePi/nightly/2018-06-28_2018-04-18-realtimepi-stretch-lite-0.4.0.zip
(md5: 6bbc1c3bc5d2d1e51e990660690dff7c)

And:
http://unofficialpi.org/Distros/RealtimePi/nightly/2018-06-28_realtimepi-kernel-4.14.43.tar.gz

For example.

Do we want to post this somewhere outside this small commit thread?

@pelwell
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice - it's good to see this resource being used.

If you want to publicise your service, start a topic in the Advanced Users forum.

@MilhouseVH
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI: The background for the revert can be found here: https://forum.libreelec.tv/thread/4235-dvb-issue-since-le-switched-to-kernel-4-9-x/?postID=75965#post75965

A related discussion can be found on LKML (https://lkml.org/lkml/2018/1/6/252) where Linus suggests an alternative solution (https://lkml.org/lkml/2018/1/8/895), however that hasn't entirely solved the initial problem either.

@guysoft
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pelwell

If you want to publicise your service, start a topic in the Advanced Users forum.

Finally got to posting here:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=218939

Please sign in to comment.