From: Con Kolivas <kernel@kolivas.org>
To: "André Goddard Rosa" <andre.goddard@gmail.com>
Cc: Lee Revell <rlrevell@joe-job.com>, Andrew Morton <akpm@osdl.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
ck@vds.kolivas.org
Subject: Re: [PATCH] mm: yield during swap prefetching
Date: Wed, 08 Mar 2006 14:05:37 +1100 [thread overview]
Message-ID: <cone.1141787137.882268.19235.501@kolivas.org> (raw)
In-Reply-To: <b8bf37780603071852r6bf3821fr7610597a54ad305b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]
André Goddard Rosa writes:
> [...]
>> > > Because being a serious desktop operating system that we are
>> > > (bwahahahaha) means the user should not have special privileges to run
>> > > something as simple as a game. Games should not need special scheduling
>> > > classes. We can always use 'nice' for a compile though. Real time audio
>> > > is a completely different world to this.
> [...]
>> Well as I said in my previous reply, games should _not_ need special
>> scheduling classes. They are not written in a real time smart way and they do
>> not have any realtime constraints or requirements.
>
> Sorry Con, but I have to disagree with you on this.
>
> Games are very complex software, involving heavy use of hardware resources
> and they also have a lot of time constraints. So, I think they should
> use RT priorities
> if it is necessary to get the resources needed in time.
Excellent, I've opened the can of worms.
Yes, games are a in incredibly complex beast.
No they shouldn't need real time scheduling to work well if they are coded
properly. However, witness the fact that most of our games are windows
ports, therefore being lower quality than the original. Witness also the
fact that at last with dual core support, lots and lots (but not all) of
windows games on _windows_ are having scheduling trouble and jerky playback,
forcing them to crappily force binding to one cpu. As much as I'd love to
blame windows, it is almost certainly due to the coding of the application
since better games don't exhibit this problem. Now the games in question
can't be trusted to even run on SMP; do you really think they could cope
with good real time code? Good -complex- real time coding is very difficult.
If you take any game out there that currently exists and throw real time
scheduling at it, almost certainly it will hang the machine. No, I don't
believe games need realtime scheduling to work well; they just need to be
written well and the kernel needs to be unintrusive enough to work well with
them. Otherwise gaming would have needed realtime scheduling from day
one on all operating systems. Generic kernel activities should not cause
game stuttering either as users have little control over them. I do expect
users to not run too many userspace programs while trying to play games
though. I do not believe we should make games work well in the presence of
updatedb running for example.
Cheers,
Con
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2006-03-08 3:05 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-07 23:13 Con Kolivas
2006-03-07 23:26 ` Andrew Morton
2006-03-07 23:32 ` Con Kolivas
2006-03-08 0:05 ` Andrew Morton
2006-03-08 0:51 ` Con Kolivas
2006-03-08 1:11 ` Andrew Morton
2006-03-08 1:12 ` Con Kolivas
2006-03-08 1:19 ` Con Kolivas
2006-03-08 1:23 ` Andrew Morton
2006-03-08 1:28 ` Con Kolivas
2006-03-08 2:08 ` Lee Revell
2006-03-08 2:12 ` Con Kolivas
2006-03-08 2:18 ` Lee Revell
2006-03-08 2:22 ` Con Kolivas
2006-03-08 2:27 ` Lee Revell
2006-03-08 2:30 ` Con Kolivas
2006-03-08 2:52 ` [ck] " André Goddard Rosa
2006-03-08 3:03 ` Lee Revell
2006-03-08 3:05 ` Con Kolivas [this message]
2006-03-08 21:07 ` Zan Lynx
2006-03-08 23:00 ` Con Kolivas
2006-03-08 23:48 ` Zan Lynx
2006-03-09 0:07 ` Con Kolivas
2006-03-09 3:13 ` Zan Lynx
2006-03-09 4:08 ` Con Kolivas
2006-03-09 4:54 ` Lee Revell
2006-03-08 7:51 ` Jan Knutar
2006-03-08 8:39 ` Con Kolivas
2006-03-09 8:57 ` Helge Hafting
2006-03-09 9:08 ` Con Kolivas
2006-03-09 22:44 ` Peter Williams
2006-03-10 9:01 ` [ck] " Andreas Mohr
2006-03-10 9:11 ` Con Kolivas
2006-03-10 0:58 ` Peter Williams
2006-03-08 22:24 ` Pavel Machek
2006-03-09 2:22 ` Nick Piggin
2006-03-09 2:30 ` Con Kolivas
2006-03-09 2:57 ` Nick Piggin
2006-03-09 9:11 ` Con Kolivas
2006-03-08 13:36 ` [ck] " Con Kolivas
2006-03-17 9:06 ` Ingo Molnar
2006-03-08 8:48 ` Andreas Mohr
2006-03-08 8:52 ` Con Kolivas
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=cone.1141787137.882268.19235.501@kolivas.org \
--to=kernel@kolivas.org \
--cc=akpm@osdl.org \
--cc=andre.goddard@gmail.com \
--cc=ck@vds.kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rlrevell@joe-job.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox