From: raz ben yehuda <raziebe@013.net>
To: Len Brown <lenb@kernel.org>
Cc: raz ben yehuda <raziebe@013.net>,
lkml <linux-kernel@vger.kernel.org>,
linux-rt-users@vger.kernel.org
Subject: Re: Subject: PATCH : offline scheduler
Date: Sun, 19 Apr 2009 13:12:43 +0300 [thread overview]
Message-ID: <1240135963.3395.23.camel@raz> (raw)
In-Reply-To: <alpine.LFD.2.00.0904180032000.30751@localhost.localdomain>
first , i really appreciate having Len Brown reading my paper. you also
have my sympathy :)
On Sat, 2009-04-18 at 00:44 -0400, Len Brown wrote:
> On Sat, 18 Apr 2009, raz ben yehuda wrote:
>
> > Len Hello
> > offsched is a platform aimed to assign a service to an off-lined processor.
> > Motivation is explained in:
> > http://sos-linux.svn.sourceforge.net/viewvc/sos-linux/offsched/trunk/Documentation/OFFSCHED.pdf
> > Currently I have implemented two services:
> >
> > HYBRID REAL TIME LINUX
> > Implemented as a A 1us timer. This timer shows how a true real time system may co-exist with a
> > regular linux server. This way there is no enforcement of a real time system requirements on the
> > entire kernel. Full documentation is at:
> > http://sos-linux.svn.sourceforge.net/viewvc/sos-linux/offsched/trunk/Documentation/OFFSCHED-RT.pdf
> >
> > RTOP
> > This piece of software send system statistics to a remove server.
> > The user benefit is that even if the machine is un-accessible (remotely or locally)
> > RTOP still sends system statistics to a remote server. I have showed in a small paper what RTOP is:
> > http://sos-linux.svn.sourceforge.net/viewvc/sos-linux/offsched/trunk/Documentation/OFFSCHED-RTOP.pdf
> >
> > The patch is mostly a facility for offsched. The exporting of tasklist_lock is because RTOP is implemented as a driver
> > and it must lock the tasks list.
> > This is the 4-th post. I will be grateful for your reply.
> >
> > Signed-off-by: Raz Ben Yehuda <raziebe@013.net.il>
> >
> > arch/x86/kernel/process.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> > arch/x86/kernel/smpboot.c | 11 +++++++----
> > include/linux/cpu.h | 20 ++++++++++++++++++++
> > include/linux/sched.h | 2 +-
> > kernel/cpu.c | 1 +
> > kernel/fork.c | 6 ++++++
> > 6 files changed, 77 insertions(+), 5 deletions(-)
>
>
> Interesting project Raz, must have been fun to develop!
>
> A couple of comments...
>
> It would probably be of most interest to Ingo and the RT guys on
> linux-rt-users@vger.kernel.org rather than the ACPI guys
> on linux-acpi@vger.kernel.org. (cc updated)
>
> I don't understand the utility of the "offline timer"
> use in section 6.1 of the paper.
> With Nehalem, Intel is finally shipping a hardware TSC that is
> guaranteed to be C-state, P-state, T-state invarient and not to drift --
> so an extremely accurate cycle counter is just an MSR read away
> on all cores...
>
I was not clear . I meant timer and not a clock. Having a more accurate
TSC is even better, because reading from hpet or cmos clocks
takes too long time.
> I also don't understand 6.2, the system monitor use --
> for the hardware also provides numerous perfmon counters
> in hardware for monitoring, and exposing those in a friendly way
> seems to me to be a more interesting exercise than
> trying to do monitoring in software with a dedicated CPU.
rtop is meant to be used only when you cannot access the machine because it is
too overloaded. RTOP pushes information out from the system.
> For 6.3, the traffic shaper...
> The newer NICs have dedicated hardware to detect and shape
> traffic flows -- again, probably much more efficient than
> dedicating a general purpose processor...
You are correct.I think i will design a new kind of offlet, one than can offload
the entire tcp stack, this way i will have nice ultra fast web server. I
cannot rely on TOE as a general solution for all interfaces. and I do
not think TOE is support ether channeling.
> For RT...
> Certainly the performance of a dedicated CPU would be
> what the rt kernel would want to strive for. I guess
> the question is if you can measure an actual performance
> difference to quanitfy the theoretical beneifts
> of the lack of locks, lack of protection etc.
well, you are correct , again. i will provide benchmarks(if my
tutor will allow me to change my plans that is).
> cheers,
> Len Brown, Intel Open Source Technology Center
>
>
prev parent reply other threads:[~2009-04-19 7:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-17 22:11 Subject: PATCH : offline scheduler raz ben yehuda
2009-04-18 4:44 ` Len Brown
2009-04-19 10:12 ` raz ben yehuda [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1240135963.3395.23.camel@raz \
--to=raziebe@013.net \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.