| News | Features | Interviews |
| Blog | Contact | Editorials |
| SCHED_DEADLINE v6 released |
| By special contributor cloud on 2012-10-27 01:05:38 |
| A new version of the real-time Linux scheduler called SCHED_DEADLINE has been released on the Linux Kernel Mailing List. For people who missed previous submissions, it consists of a new deadline-based CPU scheduler for the Linux kernel with bandwidth isolation (resource reservation) capabilities. It supports global/clustered multiprocessor scheduling through dynamic task migrations. This new version takes into account previous comments/suggestions and is aligned to the latest mainline kernel. A video about SCHED_DEADLINE is also available on YouTube. |
|
| RE[3]: lie-nux at it again. |
| By MOS6510 on 2012-10-27 21:20:22 |
|
I'm a quite able Linux user and I have to fiddle around with Windows XP/7 on a regular basis while I personally use OS X. Sadly I have reached a stage in my life where I don't have the time or motivation to check out Linux distributions, testdrive different GUIs or build my own PC. There was a time when I did this and I'm happy it's over. Linux desktops are fast, even heavy ones like KDE, but my gripe is with the application software. IMO it's just not good, certainly when compared to Windows and OS X counterparts. There is some good software, but in few numbers. When I use Linux I prefer CLI only. That's fun to use and all the CLI commands and programs are very useful, powerful and just work. |
 - Score: 5 |
| RE[17]: lie-nux at it again. |
| By Laurence on 2012-10-27 21:26:37 |
|
> I only complain that some tools require a lot of dependancies, a lot in number and in bytes. Some of which aren't always logical on first (or second) sight. Sometimes you want to check something out, a utility of 23 KB, then 31 MB gets downloaded, the utility doesn't work, you deinstall it and free up 23 KB. I've not used Debian extensively, so I can't comment on apt-get specifically, but other distros do remove dependancies like you'd prefer. However you keep making comparisons to Windows, yet Windows doesn't do any dependancy management what so ever. If an application says it requires a specific framework, then the user is required to download and install that themselves and subsiquently uninstall it themselves when they're done. > But at least we can agree that the GUI isn't really a dependency for Windows and OS X, as they already have one. Sorry but that comment is just retarded. You're bitching that Debian asked you to install a GUI then complimenting Windows and OS X for having one pre-installed. That kind of backwards logic helps no one. > I'm not complaining that Linux needs to be more like Windows or OS X, I'm fine with it like it is. My only point is that "dependencies" are much more of an issue than they are on Windows and OS X. No doubt you can find issues with Windows and OS X that aren't so on Linux. Well yeah, like I said before, shared objects in Linux suck at times. I'm not going to dispute that. But the examples you've given have been pretty poor: * You complain about having to install a GUI on Linux despite it being mandatory on Windows and OS X. * You complain about the size of dependancies on Debian, despite it still having a significantly lower foot print than Windows and OS X * You complain about how you're not spoon-fed, despite running an enterprise distro instead of a user-centric one * and you comment about how good OS X is for auto-downloading a Java plug in, yet bitch about Debian for doing the same thing with it's dependancies. Nearly every single example you've given has boarded on hypocracy. Which, sadly, undermines the whole point you're trying to raise. But I suspect (and please feel free to shoot me down if I'm wrong here) that's because you haven't spent a massive amount of time on Linux nor Windows platforms so rather than offering a solid technical understanding, you're having to explain your points with anacdotal evidence? If that's the case then that's fair enough and I'll happily chat in more detail about how Linux shared libraries differ from Windows share libraries and why that makes Windows more user friendly. But just be aware that the evidence you've cited in this thread doesn't really support the points you're trying to raise. > You've never used Windows update then ;) Well, I have and the only thing I don't like about it that on a new install it says that there are X updates and after installing them and rebooting it turns out there are more updates and after another reboot it again offers some updates. Yup, that's because Windows can't do any dependacy resolution so it has to do each update in sequence rather than just nabbing all the latest patches. > Most Windows software just installs and it if needs something extra it will download/install it automatically. We may never agree on this, but I do genuinely think installing applications on Linux is easier. If it wasn't, Apple and MS wouldn't be mimicing Linux repositories with their own centralised software repositories. |
| - Score: 5 |
| RE[5]: lie-nux at it again. |
| By Alfman on 2012-10-27 21:33:12 |
|
Laurence, "If Linux gets exhausted of RAM, then the requesting application is killed and an OOE (out of memory exception) raised in the event logs." Isn't the default behaviour under linux to call the out of memory killer? It takes over and heuristically decides which process to kill. I'm opposed to the OOM killer on the grounds that it randomly kills well behaved processes, even when they handle out of memory conditions in a well defined way. Playing devil's advocate, OOM killer gives the user a chance to specify weight factors for each process to give the kernel a hint about which processes to kill first (/proc/1000/oom_adj /proc/1000/oom_score etc). This increases the likelihood that the kernel will kill a process that is responsible for consuming the most ram. Without the OOM killer, a small process (ie ssh) can be forced to terminate when another process (dd bs=4G) is responsible for hoarding all the memory. Killing the large "guilty" process is better than killing small processes that happen to need more memory. I am interested in what others think about the linux OOM killer. "mv `which dd` /sbin/ problem solved." I don't think that addresses the root concern, which is that userspace processes can abuse system resources to the point of grinding the system to a halt. dd was a simple example, but there are infinitely more ways to do similar things. If our goal was to deny access to all the commands with potential to overload system resources, we'd be left with a virtually empty set. Obviously you'd have to deny access to php, perl, gcc, even shell scripts. The following does an excellent job of consuming both CPU and RAM on my system until I run out of memory and it aborts: cat /dev/zero | gzip -c | gzip -d | gzip -c | gzip -d | gzip -c | gzip -d | sort > /dev/null It's not likely to happen accidentally, but if a user is determined to abuse resources, he'll find a way! |
| - Score: 2 |
| RE[6]: lie-nux at it again. |
| By Laurence on 2012-10-27 21:35:35 |
|
> That just takes care of one tool which can bring the system to its knees, limiting access to dd is a bandage. The issue is that any application on Linux can cause the system a great deal of stress or bring it down. (I do this a couple of times a year by accident.) There are ways to protect against this kind of attack (accidental or not) such as setting resource limits on user accounts. Most distributions do not appear to ship with these in place by default, but if your system requires lots of uninterrupted uptime, the sysadmin should consider locking down resource usage. It the same case for all OSs though. Trying to open a 200MB Excel spreadsheet that some office idiot decided to build a database in will easily bring Windows to it's knees. The moment you put an idiot in front a computer than that machine is as good as dead. Regardless of the OS. There's a saying that goes something like "The more you dumb something down, the bigger idiot that come along". |
| - Score: 5 |
| RE[6]: lie-nux at it again. |
| By Alfman on 2012-10-27 21:37:58 |
|
jessesmith, "The issue is that any application on Linux can cause the system a great deal of stress or bring it down. " Agree with your post, however let's expand that to ANY multiuser OS, be it UNIX (freebsd, linux, osx, etc), windows terminal server, citrix, etc. |
| - Score: 3 |
| RE[6]: lie-nux at it again. |
| By Laurence on 2012-10-27 21:44:23 |
|
> Isn't the default behaviour under linux to call the out of memory killer? It takes over and heuristically decides which process to kill. Well yeah, that's what i just said. > I'm opposed to the OOM killer on the grounds that it randomly kills well behaved processes, even when they handle out of memory conditions in a well defined way. Yeah, i've often wondered if there was a better way of handling such exceptions. OOM doesn't sit nicely with me either. > Playing devil's advocate, OOM killer gives the user a chance to specify weight factors for each process to give the kernel a hint about which processes to kill first (/proc/1000/oom_adj /proc/1000/oom_score etc). This increases the likelihood that the kernel will kill a process that is responsible for consuming the most ram. Without the OOM killer, a small process (ie ssh) can be forced to terminate when another process (dd bs=4G) is responsible for hoarding all the memory. Killing the large "guilty" process is better than killing small processes that happen to need more memory. Interesting concept. A little tricky to impliment I think, but it has potential. > I don't think that addresses the root concern, which is that userspace processes can abuse system resources to the point of grinding the system to a halt. dd was a simple example, but there are infinitely more ways to do similar things. If our goal was to deny access to all the commands with potential to overload system resources, we'd be left with a virtually empty set. Obviously you'd have to deny access to php, perl, gcc, even shell scripts. The following does an excellent job of consuming both CPU and RAM on my system until I run out of memory and it aborts: cat /dev/zero | gzip -c | gzip -d | gzip -c | gzip -d | gzip -c | gzip -d | sort > /dev/null It's not likely to happen accidentally, but if a user is determined to abuse resources, he'll find a way! But that's true for any OS. If a user has access to a machine then it would only take a determined halfwit to bring it to it's knees. The only 'safe' option would be to set everyone up with thin clients which only have a web browser installed and bookmarked link to cloud services like Google Docs. |
| - Score: 2 |
| RE[3]: lie-nux at it again. |
| By WereCatf on 2012-10-27 21:49:29 |
|
> You sure? I get dd: memory exhausted by input buffer of size 4294967296 bytes (4,0 GiB) Lowering to bs=1G, dd will complete without much noticeable slowdown. Well, that is actually the expected behaviour on an average desktop-oriented distro. Of course allocating 4 gigabytes of contiguous memory on a system that do not have that much is going to slow down or fail, you can perfectly well try that on Windows and OSX and get exactly the same thing. Now, before you go ahead and try to say this is a fault in Linux I have to enlighten you that it's actually a perfectly solveable problem. Forced pre-emption enabled in the kernel, a proper I/O scheduler and limiting either I/O or memory-usage per process or per user will solve that thing in a nice, clean way, without breaking anything in userland and provide for a functional, responsive system even with such a dd going in the background. If you're interested peruse the kernel documentation or Google around, there's plenty of documentation on exactly this topic. These are, however, not used on desktop systems because usually desktop systems are only utilized by one person at a time and they do not have the need for such and therefore it's rather misguided to even complain about that -- these are features that are aimed at enterprise servers and require some tuning for your specific needs. EDIT: Some reading for those who are interested: http://en.wikipedia.org/wiki/Cgr... http://git.kernel.org/?p=linux/k... http://git.kernel.org/?p=linux/k... Edited 2012-10-27 21:56 UTC |
| - Score: 6 |
| RE[7]: lie-nux at it again. |
| By Alfman on 2012-10-27 22:11:19 |
|
Laurence, "Well yeah, that's what i just said." "Interesting concept. A little tricky to impliment I think, but it has potential." Maybe we're misunderstanding each other, but the OOM killer I described above *is* what linux has implemented. When it's enabled (I think by default), it does not necessarily kill the requesting application, it heuristically selects a process to kill. "The only 'safe' option would be to set everyone up with thin clients which only have a web browser installed and bookmarked link to cloud services like Google Docs." Haha, I hear you there, but ironically I consider firefox to be one of the guilty apps. I often have to kill it as it reaches 500MB after a week of fairly routine use. I'm the only one on this computer, but if there were 4 or 5 of us it'd be a problem. This is probably hopeless, but here is what top prints out now: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27407 lou 20 0 1106m 403m 24m R 4 10.0 50:27.51 firefox 21276 lou 20 0 441m 129m 5420 S 3 3.2 869:47.14 skype I didn't realise skype was such a hog! |
| - Score: 2 |
| RE[7]: lie-nux at it again. |
| By Gullible Jones on 2012-10-28 00:39:53 |
|
But that's true for any OS. If a user has access to a machine then it would only take a determined halfwit to bring it to it's knees. Have to disagree; IMO the entire goal and purpose of a multiuser OS is to prevent users from stepping on each other's toes. Obviously some of this is the sysadmin's responsibility; but I do think it's good to have default setups that are more fool-proof in multiuser environments, since that's probably where Linux sees the most use. (I think?) That said, operating systems are imperfect, like the humans that create them. Re handling of OOM conditions. IIRC the BSDs handle this by making malloc() fail if there's not enough memory for it. From what I recall of C, this will probably cause the calling program to crash, which I think is what you want in most cases - unless the calling program is something like top or kill! But I doubt you'd easily get conditions where $bloatyapp would keep running while kill would get terminated. (Linux has a couple options like this. The OOM killer can be set to kill the first application that exceeds available memory; or you can set the kernel to make malloc() fail if more than a percentage of RAM + total swap would be filled. Sadly, there is as of yet no "fail malloc() when physical RAM is exceeded and never mind the swap" setting.) |
| - Score: 2 |
| RE[3]: lie-nux at it again. |
| By Gullible Jones on 2012-10-28 00:43:29 |
|
If Linux gets exhausted of RAM, then the requesting application is killed and an OOE (out of memory exception) raised in the event logs. Not quite true, that's what Linux should do. ;) What Linux usually does (unless vm.oom_kill_allocating_task is set to 1) is attempt to kill programs that look like memory hogs, using some kind of heuristic. In my experience, that heuristic knocks out the offending program about half the time... The other half the time, it knocks out X. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |