Difference between revisions of "Session:Embedded is not special KR 2012"

From eLinux.org
Jump to: navigation, search
m
m (Transcript)
Line 162: Line 162:
 
9:00 - 10:00:
 
9:00 - 10:00:
  
Yeah, absolutely, everybody cares. There's nothing that is solely an embedded concern.
+
Yeah, absolutely, everybody cares.  
  
 
[Slide 13 - User interfaces]
 
[Slide 13 - User interfaces]
 +
 +
There's nothing that is solely an embedded concern.
  
 
And user interfaces as well. There are some specific requirements for handheld touchscreens but really these also cross the board.
 
And user interfaces as well. There are some specific requirements for handheld touchscreens but really these also cross the board.
 +
 +
[Slide 14 - User interfaces]
 +
 
We've seen.. Um.. i don't know if they are even very popular but a lot of the concepts do actually make a lot of sense and we've seen that user interface development driven to a certain extent by requirements elsewhere so, yeah.. netbook in particular needs the uncluttered user environment.
 
We've seen.. Um.. i don't know if they are even very popular but a lot of the concepts do actually make a lot of sense and we've seen that user interface development driven to a certain extent by requirements elsewhere so, yeah.. netbook in particular needs the uncluttered user environment.
  
And so, there is so much that is not a requirement for embedded. This is why i don't like talking about "Embedded Linux"
+
[Slide 15 - Solid state storage]
 +
 
 +
And so, there is so much that is not a requirement for embedded. This is why i don't like talking about "Embedded Linux".
  
 
I like to think there is no such thing as "Embedded Linux". There is just Linux.
 
I like to think there is no such thing as "Embedded Linux". There is just Linux.
  
 
10:00 - 11:00:
 
10:00 - 11:00:
 +
 +
So, flash storage. Um..
 +
 +
[Slide 16 - Solid state storage]
 +
 +
We have flash storage in embedded devices but we are increasingly seeing SSDs in laptops, even in servers.
 +
So again, despite me seeing earlier I'd like to see proper flash access in embedded devices. We do seem to be moving towards more and more embedded devices even new android devices having the fake disk: an SSD, an SD card and so, essentially, that's the same type of technology from the embedded device all the way up to the big iron.
 +
 +
And so we care about the same things.. You know.. Getting TRIM working, getting the device sleep working.. All the things that allow us to work around the problems of the "pretend to be a disk" approach. We care about that. Everywhere from..
  
 
11:00 - 12:00:
 
11:00 - 12:00:
 +
 +
[inaudible question from the audience]
 +
 +
Sorry, What was the question?
 +
 +
[question from audience about whether linux kernel is used inside a SSD]
 +
 +
Inside an SSD? No.
 +
 +
It will be a microkernel of some kind. You know.. A tiny RTOS of some kind. Its very..
 +
You could do, but its very unlikely to be a Linux kernel but there are as many answers to that question as there are different SSDs from different vendors of course. But basically, i don't know of any that would be using Linux
 +
 +
Linux is a good fit for many things but that isn't one of the things that linux is great at. In fact, I spent a lot of time saying that in the early days of "Embedded Linux"... "yes we love linux but don't try to use it for this" and that is one of those i think
  
 
12:00 - 13:00:
 
12:00 - 13:00:
 +
 +
[Slide 17 - Others...]
 +
 +
So Execute In Place, um.. In the days of NOR flash which could be mapped as ROM and the CPU could access the data directly and run code from it directly it was very useful to have execute in place support so that rather than copying your code, your kernel, whatever, from flash into RAM and running it from there you could actually run it in place this meant that on a tiny device you could get away with a lot less RAM and a much faster startup time at a cost of the fact that running from flash will be slower... just because RAM goes faster.
 +
 +
So execute in place was really useful for that.
 +
 +
But in fact it turns out that execute in place and all the horrible tricks we have to play in the VM to map this page here, this physical thing that isn't RAM, map it in as a page cache, a page of a file etc.
  
 
13:00 - 14:00:
 
13:00 - 14:00:
 +
 +
that's really useful for virtualisation as well so that support which actually eventually gave us execute in place in the kernel did not come from embedded developers
 +
it came from IBM working on S390
 +
 +
So that their virtual machines could share underlying disk devices and map. Basically, the host, the hypervisor, would load a page from the disk into RAM and that physical page would then be shared into all the virtual machines using the same execute in place methodology throughout the linux virtual memory system.
 +
 +
So again, its not just embedded.
 +
 +
[inaudible question from audience]
 +
 +
It has to be supported by the hardware, yes.
  
 
14:00 - 15:00:
 
14:00 - 15:00:
 +
 +
but there is a software issue in that the virtual memory management system in linux has to be able to cope with the fact that we're not just managing standard pages of RAM that can be read and written to and made dirty and then written back to disk which is basically how all the memory management worked with flags on pages to mark them as dirty and needing writeback etc. You had to cope with the fact that actually what I'm doing is here, is when the userspace memory maps a bit of file, I am giving them physical access directly to the original copy which i must not write to. I cannot write to. Its ROM essentially. and so if they are going to try to write to it, we then have to copy it into a page in RAM and do copy on write etc. The complicated part of that was software. The hardware part, while necessary, from our point of view that was simple either its possible or its not.
 +
 +
If its possible then we have to do the software to cope, right? So the complicated part was the software, yeah.
  
 
15:00 - 16:00:
 
15:00 - 16:00:
 +
 +
From the hardware point of view, in the embedded case of.. You know.. ROM, oh you know execute in place from flash the flash was there, there was a physical address
 +
for the flash which was not RAM and all you have to do is map it, but that was the complicated part.
 +
 +
And DMA APIs. So when you are doing.. when using a peripheral to DMA to or from memory.
 +
 +
A lot of the smaller systems had cache coherency issues so that you had to make sure you flushed the caches at the right time.
 +
 +
Basically um it was a big problem for a lot of drivers, a lot of network drivers in particular, wouldn't get it right. They'd just say right here is your address go
 +
and do it and would fail when you put that same device into an embedded system.
 +
 +
Um.. and they wouldn't use the DMA API properly.
  
 
16:00 - 17:00:
 
16:00 - 17:00:
 +
 +
but we need them to because.. you know.. bigger systems have an I/O MMU now so if you just pick a physical address from the ether and give it to you device
 +
it won't work. So now we are seeing all of the drivers being fixed to use the DMA API properly so that they can work with.. you know.. current Intel/AMD systems
 +
Um.. with I/O MMU and this means those same drivers are fixed for the embedded use case where we need to use the same API for different reasons. So its just another case. I can't think of many things which really are embedded specific.
 +
 +
[Slide 18 - We are not so special!]
 +
 +
We are not that special. I don't like talking about "Embedded Linux".
 +
 +
I am one of the "Embedded Linux" maintainers for my sins but only under protest because Andrew Morton kind of insisted on there being somebody to do that.
 +
and you know most of what I do in that role which is very very little is to say this is not embedded this is.. You know.. This is generic.
  
 
17:00 - 18:00:
 
17:00 - 18:00:

Revision as of 05:25, 28 February 2013

Session Details

Event 
Kernel Recipes Paris 2012
Date 
September 21, 2012
Presenter 
David Woodhouse
Organization
Intel
Slides 
https://kernel-recipes.org/?page_id=412
Video 
https://kernel-recipes.org/?page_id=412
Duration 
35:48

Abstract

How embedded Linux isn’t so special, and most of the « embedded requirements » are also requirements in « big iron » too

Biography

Notes

Transcript

Transcribed by
Chris Dudding
Verified by

0:00 - 1:00:

[Slide 1 - Embedded Linux and the mainline kernel]

>> DAVID WOODHOUSE: Um. I'm going to talk about "Embedded Linux" and what it means to me. Um. And how I dislike talking about "Embedded Linux" and the mainline kernel and how to work with it. Um. So.. [Speaker attempts to switch slide] Oh come on.. Please.. I'm going to talk about Open Office and how I hate it [Laughter from audience]

[Slide 2 - Where does Linux run?]

Wahey! So, Linux is everywhere. You see it on all kinds of devices: control devices, phones, all the way up to supercomputers, mainframes. Everybody runs Linux. Um. And we talk about "Embedded Linux" but what does it mean?

1:00 - 2:00:

You know.. Some people talk about "Embedded Linux" and include this kind of thing

[Speaker points to server image on slide]

It doesn't have a screen and a keyboard. It doesn't have a user with a graphical desktop. It must be embedded right?

Um.. So we use the term "Embedded Linux" to cover all manner of evils.

[Slide 3 - "Embedded"...?]

Um.. And a lot of the time when you hear sort of people in the linux development community talking about "Embedded Linux" mostly its a code word for stuff we don't want to have to care about. Um.. But its increasingly important. There are millions of android devices out there.. really.. you know.. pushing the focus on "Embedded Linux" so a lot more people admit that we have to care about it than used to admit this.

[Slide 4 - "Embedded"...?]

And.. You know.. We can consider a lot of things to be embedded even up to perhaps.. um.. devices like netbooks, ultrabooks, tablets. They aren't necessarily the.. um.. typical thing you might have thought of when you think of "Embedded Linux"

2:00 - 3:00:

But they have a lot of the same requirements. Um..

So what makes an embedded device? Is it the fact that it is headless? That it doesn't have a screen and a keyboard? Is it the fact that it is hand-held battery powered? Um.. Cares about power management deeply. Um.. Is it the physical size? I mean is it the constraints of the hardware? The RAM? The storage? The CPU? What else makes embedded?

[gesture to audience]

What do you think?

[inaudible answer from audience]

Dedicated usage? Yes, that's common. That's a common criteria

[answer from audience: non x86 processor]

Yes, so my Mac G5 is embedded? Actually it is, i moved a month ago, it is still packed in boxes. But, yeah. non x86. That's common. Anything else?

3:00 - 4:00:

[inaudible answer from audience]

Sorry?

[answer from audience: No X11]

No X11. Yes, that's true. So there are all kinds of things that people mean when they talk about "Embedded Linux". Um.. But there are a number of things that are quite common.

[Slide 5 - Embedded needs]

Power management is a very common requirement. When people talk about "Embedded Linux" often they think about power management. We need to conserve battery at all costs. We need to shutdown any circuitry which isn't in use right now. We need aggressive run-time power management.

We also think about fast startup. You take your phone out of your pocket, turn it on, there are legal requirements about how soon you must be able to make an emergency call and even in consumer devices outside that. You know.. You have to be able get a consumer experience quickly when they turn a device on. And that's one of the things that people care about a lot when they are talking about "Embedded Linux"

Again, headless operation, we covered this didn't we, no X11

4:00 - 5:00:

So, sometimes no user interface at all when its just an embedded control device. A router. Something like that. Um..

But we care about.. when we do have a user interface.. we care about having clean user interfaces. User interfaces that work on a small screen. That work with a touch screen and that's a common theme as well.

And we care about solid state storage. i'm not going to go [pauses to rephrase] Excuse me. I'm not going to go into any more detail about solid state storage so don't worry

[Slide 6 - Embedded needs]

So these are our needs, but they are not specific to "Embedded Linux". None of them are specific to "Embedded Linux". Everybody else needs these. There is actually a huge cross over between what we need in the "embedded" space and what people doing big iron want as well.

So let's take a look at power management

5:00 - 6:00:

[Slide 7 - Power Management]

We care about it, for embedded, for battery life. We want to make our devices last as long as possible before they shutdown.

[Slide 8 - Power Management]

In a data centre with huge racks of machines running a server farm, what do you care about? You care about power management because you don't want to be running at full cost.. You know.. Running everything at full tilt.. Paying for the electricity to run.. To waste heat.. Paying for the electricity to run your air conditioning at full blast to get the heat out of the building again so you're paying for it twice. Um.. And so actually the power management requirement all the requirement for runtime power management on linux systems. This isn't an embedded requirement at all. This is something everybody cares about and nowdays they are starting to realise they do. So we are seeing a lot more.. Um.. Acceptance of this kind of.. Um.. requirement

6:00 - 7:00:

and we have seen some very good work going in to the linux kernel recently on power management where maybe ten years ago there was a lot more resistance from upstream with people saying "oh we don't care about this kind of thing.. Why would we care".

[Slide 9 - Tickless operation]

So tickless operation. We heard about tickless.. um.. kernel earlier. Um.. And yes, this is really useful.. It gives us big power savings when we are running on battery.. When we don't have to wake up the CPU every thousanth of a second, hundredth of a second and do stuff, just to realise we can go back to sleep again. So, that's great. That's an embedded requirement.

[Slide 10 - Tickless operation]

But, its not just an embedded requirement. If you think about big farms of virtual servers.. the big hosting farms running lots of virtual machines they absolutely do not want every virtual machine every one of thousands of virtual machines waking up every millisecond

7:00 - 8:00:

and doing all this gratuitous stuff just to go back to sleep again because that means that the hypervisor has then got to run every single virtual machine.. And the cost of that is insane you can actually have.. You know.. The physical hardware.. The hypervisor doing nothing but running the timer tick on thousands of virtual machines and having no time to do any real work.

So again we have tickless operation which is not just an embedded requirement.. Its something that we need everywhere.

[Slide 11 - Fast boot]

Fast boot, so i talked about this. We have requirements for mobile phones that you have to be able to make calls within a certain amount of time and its just a very important user experience requirement for many.. You know.. Tablet devices, ultrabooks etc.

We care deeply about fast boot.

There has been a lot of work going into Linux distributions to boot fast, it gets you to the login screen or to the working environment as quickly as possible.

8:00 - 9:00:

[Slide 12 - Fast boot]

But, you might guess where I'm going with this, Um.. big iron needs it too.

If you've got a server hosting some service and you've promised 99.999% availability, how many seconds a year are you allowed to be down? That's less than one reboot. You need to reboot. [speaker re-phrases] If you have to reboot, you're eating into your uptime guarantee very very quickly so you need your servers to come back quickly. Um..

And so fast boot is not just embedded. Its for everybody. Everybody cares.

AUDIENCE>> Even on a netbook there?

>> DAVID WOODHOUSE: Yeah, everybody. Absolutely. Yeah, I care if I get up to the front here, boot up my laptop and you're waiting for 5 minutes while it boots up and I can't do my presentation. Or if you're waiting for 5 minutes while we try to drive Open Office. Um..

9:00 - 10:00:

Yeah, absolutely, everybody cares.

[Slide 13 - User interfaces]

There's nothing that is solely an embedded concern.

And user interfaces as well. There are some specific requirements for handheld touchscreens but really these also cross the board.

[Slide 14 - User interfaces]

We've seen.. Um.. i don't know if they are even very popular but a lot of the concepts do actually make a lot of sense and we've seen that user interface development driven to a certain extent by requirements elsewhere so, yeah.. netbook in particular needs the uncluttered user environment.

[Slide 15 - Solid state storage]

And so, there is so much that is not a requirement for embedded. This is why i don't like talking about "Embedded Linux".

I like to think there is no such thing as "Embedded Linux". There is just Linux.

10:00 - 11:00:

So, flash storage. Um..

[Slide 16 - Solid state storage]

We have flash storage in embedded devices but we are increasingly seeing SSDs in laptops, even in servers. So again, despite me seeing earlier I'd like to see proper flash access in embedded devices. We do seem to be moving towards more and more embedded devices even new android devices having the fake disk: an SSD, an SD card and so, essentially, that's the same type of technology from the embedded device all the way up to the big iron.

And so we care about the same things.. You know.. Getting TRIM working, getting the device sleep working.. All the things that allow us to work around the problems of the "pretend to be a disk" approach. We care about that. Everywhere from..

11:00 - 12:00:

[inaudible question from the audience]

Sorry, What was the question?

[question from audience about whether linux kernel is used inside a SSD]

Inside an SSD? No.

It will be a microkernel of some kind. You know.. A tiny RTOS of some kind. Its very.. You could do, but its very unlikely to be a Linux kernel but there are as many answers to that question as there are different SSDs from different vendors of course. But basically, i don't know of any that would be using Linux

Linux is a good fit for many things but that isn't one of the things that linux is great at. In fact, I spent a lot of time saying that in the early days of "Embedded Linux"... "yes we love linux but don't try to use it for this" and that is one of those i think

12:00 - 13:00:

[Slide 17 - Others...]

So Execute In Place, um.. In the days of NOR flash which could be mapped as ROM and the CPU could access the data directly and run code from it directly it was very useful to have execute in place support so that rather than copying your code, your kernel, whatever, from flash into RAM and running it from there you could actually run it in place this meant that on a tiny device you could get away with a lot less RAM and a much faster startup time at a cost of the fact that running from flash will be slower... just because RAM goes faster.

So execute in place was really useful for that.

But in fact it turns out that execute in place and all the horrible tricks we have to play in the VM to map this page here, this physical thing that isn't RAM, map it in as a page cache, a page of a file etc.

13:00 - 14:00:

that's really useful for virtualisation as well so that support which actually eventually gave us execute in place in the kernel did not come from embedded developers it came from IBM working on S390

So that their virtual machines could share underlying disk devices and map. Basically, the host, the hypervisor, would load a page from the disk into RAM and that physical page would then be shared into all the virtual machines using the same execute in place methodology throughout the linux virtual memory system.

So again, its not just embedded.

[inaudible question from audience]

It has to be supported by the hardware, yes.

14:00 - 15:00:

but there is a software issue in that the virtual memory management system in linux has to be able to cope with the fact that we're not just managing standard pages of RAM that can be read and written to and made dirty and then written back to disk which is basically how all the memory management worked with flags on pages to mark them as dirty and needing writeback etc. You had to cope with the fact that actually what I'm doing is here, is when the userspace memory maps a bit of file, I am giving them physical access directly to the original copy which i must not write to. I cannot write to. Its ROM essentially. and so if they are going to try to write to it, we then have to copy it into a page in RAM and do copy on write etc. The complicated part of that was software. The hardware part, while necessary, from our point of view that was simple either its possible or its not.

If its possible then we have to do the software to cope, right? So the complicated part was the software, yeah.

15:00 - 16:00:

From the hardware point of view, in the embedded case of.. You know.. ROM, oh you know execute in place from flash the flash was there, there was a physical address for the flash which was not RAM and all you have to do is map it, but that was the complicated part.

And DMA APIs. So when you are doing.. when using a peripheral to DMA to or from memory.

A lot of the smaller systems had cache coherency issues so that you had to make sure you flushed the caches at the right time.

Basically um it was a big problem for a lot of drivers, a lot of network drivers in particular, wouldn't get it right. They'd just say right here is your address go and do it and would fail when you put that same device into an embedded system.

Um.. and they wouldn't use the DMA API properly.

16:00 - 17:00:

but we need them to because.. you know.. bigger systems have an I/O MMU now so if you just pick a physical address from the ether and give it to you device it won't work. So now we are seeing all of the drivers being fixed to use the DMA API properly so that they can work with.. you know.. current Intel/AMD systems Um.. with I/O MMU and this means those same drivers are fixed for the embedded use case where we need to use the same API for different reasons. So its just another case. I can't think of many things which really are embedded specific.

[Slide 18 - We are not so special!]

We are not that special. I don't like talking about "Embedded Linux".

I am one of the "Embedded Linux" maintainers for my sins but only under protest because Andrew Morton kind of insisted on there being somebody to do that. and you know most of what I do in that role which is very very little is to say this is not embedded this is.. You know.. This is generic.

17:00 - 18:00:

18:00 - 19:00:

19:00 - 20:00:

20:00 - 21:00:

21:00 - 22:00:

22:00 - 23:00:

23:00 - 24:00:

24:00 - 25:00:

25:00 - 26:00:

26:00 - 27:00:

27:00 - 28:00:

28:00 - 29:00:

29:00 - 30:00:

30:00 - 31:00:

31:00 - 32:00:

32:00 - 33:00:

33:00 - 34:00:

34:00 - 35:00:

35:00 - 36:00:

36:00 - 37:00:

37:00 - 38:00:

38:00 - 39:00:

39:00 - 40:00:

40:00 - 41:00:

41:00 - 42:00:

42:00 - 43:00:

43:00 - 44:00:

44:00 - 45:00:

45:00 - 46:00:

46:00 - 47:00:

47:00 - 48:00:

48:00 - 49:00:

49:00 - 50:00:

50:00 - 51:00:

51:00 - 52:00:

52:00 - 53:00:

53:00 - 54:00:

54:00 - 55:00:

55:00 - 56:00:

56:00 - 57:00:

57:00 - 58:00:

58:00 - 59:00:

59:00 - 60:00: