User avatar
DavidS
Posts: 4216
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

80+Tasks.

Sat Sep 28, 2013 3:42 am

Note I just switched over from RISC OS. That said I have been using Linux for 18 years, and this is the first system that I have ever used that has 80+ threads running at the X11 + FM +WM Desktop.

With X11, FM, and nothing extra. This count should be between 16 and 25 tasks not 80. What is the reasoning behind this? Is it an intentional waste of resources, or is there actually a good reason to have so many threads going?

I do not feel like editing scripts this late at night, though I would like to know the reasoning behind this, as a reconfiguration to run what is needed could greatly improve performance, and that is saying something as Raspbian performs better than I would have expected from a Debian derived Linux Distro on the RPi. Though Raspbian does also use way more RAM for that which is loaded during boot than I would have expected.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 22724
Joined: Sat Jul 30, 2011 7:41 pm

Re: 80+Tasks.

Sat Sep 28, 2013 8:49 am

Raspbian is basically debian, so same applies to that. Worth comparing with a desktop debian, I would expect similar.

That said, a non executing thread is not really a waste of resource and has minimal impact on performance.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: 80+Tasks.

Sat Sep 28, 2013 8:59 am

I rarely us X on my Pi. Even so it has 68 processes running !

Some times I wonder what they all are:)

Do I worry about them? No. When Use "top" to see what is going on I see they are all sitting there using almost zero memory and zero processor time. The most resource consuming thing is the "top" command itself at ~1% CPU load and ~0.5% memory consumption.

They are just sitting there waiting for things to do, like an ssh session, or http request, or detecting USB stuff is plugged in whatever.

You could probably find a few of those processes you can live with out but the time you spend figuring that out will never be paid back in any performance improvement.

Looking at my Debian PC running KDE and FireFox I see it has 149 processes running. Raspbian is doing quite well.

OtherCrashOverride
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am

Re: 80+Tasks.

Sat Sep 28, 2013 10:44 am

DavidS wrote:Note I just switched over from RISC OS. That said I have been using Linux for 18 years, and this is the first system that I have ever used that has 80+ threads running at the X11 + FM +WM Desktop.
My Pi reports 60 tasks (no GUI). Of those 1 is running (top command) and 59 are sleeping. Linux is pre-emptively multitasked rather than cooperatively like RISC OS. This means that a process does not need to run to check if work needs to be done. Instead an interrupt or other condition will wake it from sleep and it will get scheduled for execution. So coming from a cooperative environment, the number may seen high, but on a pre-emptive system it does not impact performance.

Using the command "ps -ef" will show you all the processes and their command line. On my system, about half are kernel processes. The others are userland processes that do things like network time, dhcp, device input, IPC, and session management.

User avatar
DavidS
Posts: 4216
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: 80+Tasks.

Sat Sep 28, 2013 12:41 pm

I am able to identify the processes and what they do. Many of them are not needed, a couple are.

As said I have been using Linux for 18 years.

As for Debian, I do have a desktop install of Debian i686 on one computer, and it has 21 tasks at a complete desktop enviroment. Debian is designed to be set up as the user wishes. For the most part for a few years I have been using Puppy Linux when I need Linux as it is easier to hack to my liking than most Linux Distros.

So yes seeing 80+ tasks taking almost 30MB of RAM is quite a surprise for any Debian, especially one that is designed to use little resources. I am aware that most of them are using zero processing time except when needed, though they are still taking a lot of memory, and the task management has to scan through that list at each time slice.

I do like Raspbian as it is pretty well done. It is obvious that many Optomizations have been done. I kind of have to use X as it is required for Electric VLSI, and many other tools that I use.

I did a quick compile on a small project last night and was surprised how much more time the compile took under Raspbian using GCC than it does under RISC OS using Norcroft C, especially as Norcroft does a much better job of optimizing on the ARMv5/6/7.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

User avatar
DavidS
Posts: 4216
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: 80+Tasks.

Sun Sep 29, 2013 3:15 am

Never mind:

I will not be using Linux at all on the RPi for now.

I attempted to assemble a test program that I had ported over from RISC OS for testing, and lo and behold it bouught down the system with a Panic.

If I can crash the OS by running gas I do not want it.

I have no interest in attempting to debug this issue, as there are perfectly good tools on RISC OS. So Linux is not a necessity.

And beings as this happened on two different Linux distros I would say that there is something up.

I do not know what caused gas to choke, though it should not have took down the system with it. Come on people even a complete noob programmer on RISC OS is not likely to release something that buggie. And on RISC OS it is easier to cause trouble for the OS if you want to.

So I will be sticking with RISC OS, at least until some provides a good fast Linux or MiNIX distro that does not choke on its own tools.

Yes this means that it is that much more importatnt for me to get the C version of Electric VLSI ported to RISC OS. So that will be what I concentrate on for now.
RPi = The best ARM based RISC OS computer around
More than 95% of posts made from RISC OS on RPi 1B/1B+ computers. Most of the rest from RISC OS on RPi 2B/3B/3B+ computers

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: 80+Tasks.

Sun Sep 29, 2013 5:30 am

DavidS,
I attempted to assemble a test program that I had ported over from RISC OS for testing, and lo and behold it bouught down the system with a Panic.
Please post your code and instructions on how you compiled/assembled it.

Perhaps there no way I can identify a problem with it but I'm fascinated to see how you did that. I have been compiling/assembling all kinds of crappy code (my own) for Linux on different ARM processors, PowerPC, and Intel for years now and very rarely I have I seen a kernel panic.

I did manage to induce a panic of my own a few times when developing device drivers but that is fair game if you are in the kernel land you are free to screw up what you like. Even then it was harder to bring the machine down than I thought.

I'm sure the Raspian developers would want to know about any such failure.

OtherCrashOverride
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am

Re: 80+Tasks.

Sun Sep 29, 2013 5:33 am

Heater wrote:Please post your code and instructions on how you compiled/assembled it.
Doubt it was code that did it. More likely suspect is over-clocking.

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: 80+Tasks.

Sun Sep 29, 2013 5:40 am

DavidS,
...they are still taking a lot of memory, and the task management has to scan through that list at each time slice.
I have to check the memory usage of all my little dormant processes.

I very much doubt that the task management is scanning through a list of all tasks on every time tick to see what is ready to run. That is how a dumb ass like me might write an operating system.

Rather, interrupt handlers will cause tasks to be moved from some "idle" list to a "ready" list or queue so that there is no list scanning going on all the time.

(Correction, my cooperative scheduler back in the late 1980s had an idle and ready list. Cooperative scheduling can be very efficient.)

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: 80+Tasks.

Sun Sep 29, 2013 5:42 am

OtherCrashOverride,
More likely suspect is over-clocking.
Something like that. That's why wee need the code and procedure, to be able to try and reproduce the failure.

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: 80+Tasks.

Sun Sep 29, 2013 6:49 am

About those 80 tasks.

We have already determined they don't cause any performance overhead, they just sit here in an idle state if they are not in use.

What about their memory wastage? The 60 odd processes on my Pi take up 28MB. No idea how much of that is actual kernel but never mind. Well that is about 10% of my available RAM. It's about the same as the RAM dedicated to the graphics. All in all not worth worrying about. It's a lot better situation than the old days of CP/M or MSDOS eating a huge chunk of your installed RAM. I suspect it's a better situation than the original RISCOS installed on an original Archimedes machine.

Of course Linux normally runs with some swap space. So if your apps actually required all physical memory those idle processes would find themselves out in swap file, where they would stay forever if you are not using them. So there would be no issue of all those threads getting in the way of what you are doing.

That only leaves the issue of boot time. Loading up processes takes time. So far that is not long enough that it worries me.

Having said all that if it still bothers people you can disable the starting of these things. If David has a list of processes we don't actually need I would like to see it. Perhaps it would help people make "lean and mean" machines.

User avatar
Cancelor
Posts: 756
Joined: Wed Aug 28, 2013 4:09 pm
Location: UK

Re: 80+Tasks.

Sun Sep 29, 2013 7:21 am

As an educational tool and knowing nothing about Linux myself I am very glad that so many things are enabled and working straight out of the box. e.g. ssh and dhcp. You see I'm learning already but I haven't had to spend hours of frustration trying to connect to the network and I haven't had to buy a dedicated display, keyboard or mouse. The desire to improve computer awareness comes before the desire to teach Linux.

Having said that, I think it is also important not to make things so easy that it is no more challenging than switching on the kettle and no more complicated than basic Lego building blocks.
Can't find the thread you want? Try googling : YourSearchHere site:raspberrypi.org

User avatar
mpthompson
Posts: 620
Joined: Fri Feb 03, 2012 7:18 pm
Location: San Carlos, CA
Contact: Website

Re: 80+Tasks.

Sun Sep 29, 2013 7:29 am

On my headless Raspbian system I use to manage my home network there are about 50 processes running with 77MB of RAM used and 160MB free. This system runs a DNS server, DHCP server, Samba mounts, VPN and a host of other things. Compared to the Debian PC based system it replaced, I didn't notice much difference between the two in terms of the number of processes running. However, the Pi takes only a few watts of power compared to 80+ watts for a PC running all the time which is a huge win in terms of power consumption.

As others have mentioned, idle tasks really don't do have much impact on performance and as long as the are doing something useful they should very likely be left alone. You can try disabling many of them in the start-up scripts (/etc/rc*** directories), but you would likely risk breaking something unless you really know what you are doing.

If you really want a minimal Raspbian system for the Raspberry Pi, it may be worth looking into using the debootstrap utility which can be used to create the absolute minimum Debian/Raspbian installation. The result would be Raspbian using just a few dozen packages running the minimum number of processes at runtime. From there you can then just use 'apt-get' to install only the absolute minimum packages desired for your system. Unfortunately, debootstrap is a tool that requires a fair amount of Linux knowledge to use correctly and is not suitable for Linux beginners.

Mike

OtherCrashOverride
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am

Re: 80+Tasks.

Sun Sep 29, 2013 8:01 am

On my Pi with a default Rasbian, the only 'bloat' processes are the extra getty instances for virtual terminals and the serial port. Everything else is used. With an uptime of 19 days, these processes have consumed 00:00:00 of cpu time (not even 1 second) according to "ps -ef".

Process count is a pretty meaningless metric. All these processes could be combined into one "super" process and I would have a task count of 3. It would not save any resources nor make my Pi any faster. Instead everything is given its own process so, for example, you do not have to reboot your system to enable networking.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 22724
Joined: Sat Jul 30, 2011 7:41 pm

Re: 80+Tasks.

Sun Sep 29, 2013 8:06 am

DavidS wrote:Never mind:

I will not be using Linux at all on the RPi for now.

I attempted to assemble a test program that I had ported over from RISC OS for testing, and lo and behold it bouught down the system with a Panic.

If I can crash the OS by running gas I do not want it.

I have no interest in attempting to debug this issue, as there are perfectly good tools on RISC OS. So Linux is not a necessity.

And beings as this happened on two different Linux distros I would say that there is something up.

I do not know what caused gas to choke, though it should not have took down the system with it. Come on people even a complete noob programmer on RISC OS is not likely to release something that buggie. And on RISC OS it is easier to cause trouble for the OS if you want to.

So I will be sticking with RISC OS, at least until some provides a good fast Linux or MiNIX distro that does not choke on its own tools.

Yes this means that it is that much more importatnt for me to get the C version of Electric VLSI ported to RISC OS. So that will be what I concentrate on for now.
What an utterly sad attitude to have.

You broke something, somehow (may or not be something you did), but don't give us details so it can be fixed, and give up straight away. How are we supposed to improve things if that happens?

As to the panic - I have no idea how you did that. I have't seen a kernel panic in years, except when doing low level stuff that you might expect would cause a kernel panic when done wrong. Linux runs perfectly fine of a huge number of machine out there with no issues whatsoever, people have had Pi's run for over a year with no problems. Hence the need to determine cause when it does happen.

As for memory usage of processes - although the system may flag up that a process is using memory (even if no CPU time), the virtual memory management system may mean the process is not actually using physical memory, so even that may be a red herring.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
Cancelor
Posts: 756
Joined: Wed Aug 28, 2013 4:09 pm
Location: UK

Re: 80+Tasks.

Sun Sep 29, 2013 8:08 am

OtherCrashOverride wrote:On my Pi with a default Rasbian, the only 'bloat' processes are the extra getty instances for virtual terminals and the serial port. Everything else is used. With an uptime of 19 days, these processes have consumed 00:00:00 of cpu time (not even 1 second) according to "ps -ef".

Process count is a pretty meaningless metric. All these processes could be combined into one "super" process and I would have a task count of 3. It would not save any resources nor make my Pi any faster. Instead everything is given its own process so, for example, you do not have to reboot your system to enable networking.
I agree, it's a bit like obsessing about how many files are on my HD. :mrgreen:
Can't find the thread you want? Try googling : YourSearchHere site:raspberrypi.org

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: 80+Tasks.

Sun Sep 29, 2013 8:43 am

jamesh,
.. the virtual memory management system may mean the process is not actually using physical memory...
Oh yeah, there is some weird stuff going on there. On my 256MB Pi I can run a program that asks for 290MB of memory and it will succeed. Of course that's impossible. The thing will only crash and burn if it tries to actually use that memory.

Before running that program the "free -m" command might say I have used 29MB of memory.
Whilst my memory eater is running the same command reports the same memory used!

Here is the memory eater code:

Code: Select all

#include <stdio.h>
#include <stdlib.h>

int main (int argc, char* argv[]) {
        void *p;
        printf ("Mallocing a big lot of memory...\n");
        p = malloc(290 * 1024 * 1024);
        if (p == NULL)  {
            printf ("Failed.\n");
        }  else  {
            printf ("OK.\n");
        }
        while(1);
        return (0);
}
P.S. Oddly mallocing 300MB does fail.

OtherCrashOverride
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am

Re: 80+Tasks.

Sun Sep 29, 2013 8:58 am

Heater wrote:Oh yeah, there is some weird stuff going on there.
Its not "weird stuff". The virtual memory system is science, not voodoo. On linux, fork is used to start a new process. This causes the virtual memory system to map the same physical pages to the new process. A copy-on-write system (CoW) is then used so that actual new memory is only allocated when necessary. Additionally, memory mapped files means that your executable may reside on disk and be discarded and reloaded without the use of swap space.

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: 80+Tasks.

Sun Sep 29, 2013 9:47 am

OtherCrashOverride,

Well, I do have a pretty good idea of what goes on with virtual memory, fork and so on.

However it is "weird". The function is called "malloc" as in "allocate memory" however that is not what it does. Having returned indicating that you have successfully allocated some memory you may later find out that you haven't been allocated it at all. In fact you (your program) may not find out, it just gets killed when it tries to use that non-existent memory.

From the malloc man page:

The malloc() function allocates size bytes and returns a pointer to the allocated memory.
The memory is not initialized. If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be success fully passed to free().


Only down in the "small print" of the NOTES section do we get a warning:

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available.

Programmers coming to Linux from other systems have been caught out by this "weird stuff".

OtherCrashOverride
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am

Re: 80+Tasks.

Sun Sep 29, 2013 10:01 am

malloc does *allocate* memory but it does not reserve it. When you 'touch' the memory a page fault occurs and the OS gives you a block of memory. This memory is virtual so its dependent on what the system can flush and what it can swap. This combination makes it difficult to calculate what is and is not available until the time you use it. By default Raspbian has 100MB swap. If you increase this, you should find your code only fails at higher allocations.

Edit:
A better way of stating it is that malloc allocates virtual address space, not memory.

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: 80+Tasks.

Sun Sep 29, 2013 11:46 am

OtherCrashOverride,
malloc does *allocate* memory but it does not reserve it.
Bah! "allocate", "reserve", all the same to me. If my hotel tells me they have "reserved" or "allocated" a room for me I will be pretty annoyed when I turn up and they have given it to someone else:)
When you 'touch' the memory a page fault occurs
Exactly, that's when you find out Linux lied lied to you. You can catch the segmentation fault signal if you don't want to die and can proceed with less memory.

BUT - In a normal Linux install the Out Of Memory Killer may well kill off your process, having been told that malloc succeeded. You have no way to catch that. You are just dead.
A better way of stating it is that malloc allocates virtual address space, not memory.
Exactly, it lies to your. Like you ISP does when it says you have bought a 100Mb/s connection. When it's a busy time you find out you have been oversold.

User avatar
jojopi
Posts: 3077
Joined: Tue Oct 11, 2011 8:38 pm

Re: 80+Tasks.

Sun Sep 29, 2013 11:50 am

Heater wrote:The function is called "malloc" as in "allocate memory" however that is not what it does.
malloc(3) calls brk(2)¹ to increase the upper limit address of your process's heap/data segment. The initial state of the new address space from brk() is "full of zeros"², so all of its pages are pointed to a single copy-on-write physical page. Further RAM and swap pages are allocated only when the memory is written to.

This is separate from memory overcommit. You can restrict or disable overcommit via proc(5) or sysctl(8). You can not, and would not want to, make brk() allocate RAM before return. Then, any big malloc() would lock the machine for seconds while other processes were swapped out to make room. And with no guarantee that the new usage would be more frequent than the old.

¹ This notation means "brk in section 2 of the manual", so "man 2 brk". The sections are explained in intro(section).

² The initial state of memory from malloc() is unspecified, because it may have been reused, but only within the current process. For security reasons the kernel will never give you memory that was used by another process without first filling or zeroing it.

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: 80+Tasks.

Sun Sep 29, 2013 12:10 pm

jojopi,

Yes, yes. But here is the deal. You start a program and it appears to run fine. You go away for a while and come back to find it dead. "Damn have to start again".

What happened?
1) Could have segfaulted when it hit the non-existent RAM it was promised at start up. A program can be written in such a way as to survive that by catching the SEGV signal.
2) The Out Of Memory killer killed it. A program cannot defend itself against the OOM Killer.

How am I going to get around the fact that malloc lied to me when my program started, and the OOM killed it whist I was away?

OtherCrashOverride
Posts: 582
Joined: Sat Feb 02, 2013 3:25 am

Re: 80+Tasks.

Sun Sep 29, 2013 12:21 pm

Heater wrote:How am I going to get around the fact that malloc lied to me when my program started, and the OOM killed it whist I was away?
Back your memory with mmap. Its like having your own personal swap file.

Heater
Posts: 12657
Joined: Tue Jul 17, 2012 3:02 pm

Re: 80+Tasks.

Sun Sep 29, 2013 12:36 pm

OtherCrashOverride,
Back your memory with mmap. Its like having your own personal swap file.
OK, now we are talking. Not quite what I wanted as that can end up as "swap" rather the the nice fast memory I asked for.

Also is it still true that the OOM killer could decide to kill my program off even if all my memory requirements were satisfied hours ago?

Got any example code?

Return to “Raspbian”