Re: [Patch] Wait for console to become available, ver 3
Hi! > Parallelization to improve boot times has been successful enough that race > conditions now exist between the init_post() open of /dev/console and > initialization of the console device. When this occurs, opening /dev/console > fails and any applications inherited from init have no standard in/out/error > devices. This is expected behavior if no console device is available, but > quite unfortunate in the case where the console is just a bit slow waking up. > > Some buses, such as USB, offer no guarantees about how long it takes to > discover devices, so there is no reliable way to distinguish between a missing > console and a slow one. The pragmatic approach taken in this patch is to > wait for a while to see if a console shows up, and just go on if it doesn't. > The default delay is 1000 msec (1 second). > > There are two new command line parameters: > consolewait Wait forever for a console to be registered > consoledelay=msec Use the given number of milliseconds as the delay > interval instead of the default Could you use rootfsdelay for this? Root needs to be mounted for init to run, so...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
> > Why is an entire filesystem needed, instead of simply a block driver > > if the ramdisk driver cannot be used? > > > > >From documentation: > > "A relatively straight-forward solution is to write a simple block > driver for the non-volatile RAM, and mount over it any disk-based > filesystem such as ext2/ext3, reiserfs, etc. > > But the disk-based fs over non-volatile RAM block driver approach has > some drawbacks: > > 1. Disk-based filesystems such as ext2/ext3 were designed for optimum >performance on spinning disk media, so they implement features such >as block groups, which attempts to group inode data into a contiguous >set of data blocks to minimize disk seeking when accessing files. For >RAM there is no such concern; a file's data blocks can be scattered >throughout the media with no access speed penalty at all. So block >groups in a filesystem mounted over RAM just adds unnecessary >complexity. A better approach is to use a filesystem specifically >tailored to RAM media which does away with these disk-based features. >This increases the efficient use of space on the media, i.e. more >space is dedicated to actual file data storage and less to meta-data >needed to maintain that file data. So... what is the performance difference between ext2 and your new filesystem? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
> >> 1. Disk-based filesystems such as ext2/ext3 were designed for optimum
> >>performance on spinning disk media, so they implement features such
> >>as block groups, which attempts to group inode data into a contiguous
> >>set of data blocks to minimize disk seeking when accessing files. For
> >>RAM there is no such concern; a file's data blocks can be scattered
> >>throughout the media with no access speed penalty at all. So block
> >>groups in a filesystem mounted over RAM just adds unnecessary
> >>complexity. A better approach is to use a filesystem specifically
> >>tailored to RAM media which does away with these disk-based features.
> >>This increases the efficient use of space on the media, i.e. more
> >>space is dedicated to actual file data storage and less to meta-data
> >>needed to maintain that file data.
> >
> > So... what is the performance difference between ext2 and your new
> > filesystem?
> >
>
> About the "space" you can read a detailed documentation on the site:
>
> http://pramfs.sourceforge.net/pramfs-spec.html
I do not see any numbers there. Do you think you can save significant
memory when storing for example kernel source trees?
> In addition I can do an example of "compact" information: ext2 uses
> directory entry objects ("dentries") to associate file names to
> inodes,
I'm not sure that on-disk directory entry == dentry.
> and these dentries are located in data blocks owned by the parent
> directory. In pramfs, directory inode's do not need to own any data
> blocks, because all dentry information is contained within the inode's
> themselves.
How do you handle hard-links, then?
> >From performance point of view:
>
> Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark
> results to compare the performance with and without XIP in a real
> embedded environment with bonnie++. You could use it as reference point.
Well, so XIP helps. ext2 can do XIP too, IIRC. Is your performance
better than ext2?
Wait... those numbers you pointed me... claim to be as slow as
13MB/sec. That's very very bad. My harddrive is faster than that.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
> > How do you handle hard-links, then? > > Indeed hard-links are not supported :) Due to the design of this fs > there are some limitations explained in the documentation as not > hard-link, only private memory mapping and so on. However this > limitations don't limit the fs itself because you must consider the > special goal of this fs. I did not see that in the changelog. If it is not general purpose filesystem, it is lot less interesting. > >> >From performance point of view: > >> > >> Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark > >> results to compare the performance with and without XIP in a real > >> embedded environment with bonnie++. You could use it as reference point. > > > > Well, so XIP helps. ext2 can do XIP too, IIRC. Is your performance > > better than ext2? > > > > Wait... those numbers you pointed me... claim to be as slow as > > 13MB/sec. That's very very bad. My harddrive is faster than that. > > As I said I did the test in a real embedded environment so to have > comparable result you should use the same environmente with the same > tools, with the same workload and so on. Even on real embedded hardware you should get better than 13MB/sec writing to _RAM_. I guess something is seriously wrong with pramfs. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
On Mon 2009-06-22 10:31:28, Tim Bird wrote: > Pavel Machek wrote: > >>> How do you handle hard-links, then? > >> Indeed hard-links are not supported :) Due to the design of this fs > >> there are some limitations explained in the documentation as not > >> hard-link, only private memory mapping and so on. However this > >> limitations don't limit the fs itself because you must consider the > >> special goal of this fs. > > > > I did not see that in the changelog. If it is not general purpose > > filesystem, it is lot less interesting. > > PRAMFS is not a general purpose filesystem. Please read > the introductory post to this thread, or look at > http://pramfs.sourceforge.net/ for more information. Yeah, I seen that. It directly contradicts what you say. > Since the purpose of PRAMFS is to provide a filesystem > that is persistent across kernel instantions, it is not > designed for high speed. Robustness in the face of > kernel crashes or bugs is the highest priority, so > PRAMFS has significant overhead to make the window > of writability to the filesystem RAM as small as possible. Really? So why don't you use well known, reliable fs like ext3? > This is not a file system one would do kernel compiles on. > This is where someone would keep a small amount of sensitive > data, or crash logs that one needed to preserve over kernel > invocations. Really? Web page says: #2. If the backing-store RAM is comparable in access speed to system #memory, there's really no point in caching the file I/O data in the #page cache. Better to move file data directly between the user buffers #and the backing store RAM, i.e. use direct I/O. This prevents the #unnecessary So you don't cache it "because its fast", and then it is 13MB/sec? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
On Mon 2009-06-22 20:07:06, Marco wrote: > Pavel Machek wrote: > > On Mon 2009-06-22 10:31:28, Tim Bird wrote: > >> Pavel Machek wrote: > >>>>> How do you handle hard-links, then? > >>>> Indeed hard-links are not supported :) Due to the design of this fs > >>>> there are some limitations explained in the documentation as not > >>>> hard-link, only private memory mapping and so on. However this > >>>> limitations don't limit the fs itself because you must consider the > >>>> special goal of this fs. > >>> I did not see that in the changelog. If it is not general purpose > >>> filesystem, it is lot less interesting. > >> PRAMFS is not a general purpose filesystem. Please read > >> the introductory post to this thread, or look at > >> http://pramfs.sourceforge.net/ for more information. > > > > Yeah, I seen that. It directly contradicts what you say. > > > > I don't think, I think it's very clear: > > "In summary, PRAMFS is a light-weight, full-featured, and > space-efficient special filesystem that is ideal for systems with a Except that it is not full-featured. No hardlinks. (What about ACLs, etc?) > block of fast non-volatile RAM that need to access data on it using a > standard filesytem interface." Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are better with ext2. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
On Mon 2009-06-22 11:55:04, Tim Bird wrote: > Pavel Machek wrote: > > On Mon 2009-06-22 10:31:28, Tim Bird wrote: > >> Pavel Machek wrote: > >>> I did not see that in the changelog. If it is not general purpose > >>> filesystem, it is lot less interesting. > >> PRAMFS is not a general purpose filesystem. Please read > >> the introductory post to this thread, or look at > >> http://pramfs.sourceforge.net/ for more information. > > > > Yeah, I seen that. It directly contradicts what you say. > > Could you be more specific? In what way does the > description on the website contradict what I said? You are saying top goal is robustness, while the web page says (home page, stop using frames!): "embedded systems have a block of non-volatile RAM seperate from normal system memory, i.e. of which the kernel maintains no memory page descriptors. For such systems it would be beneficial to mount a fast read/write filesystem over this "I/O memory", for storing frequently accessed data that must survive system reboots and power cycles" Note the "frequently accessed" and "fast". IOW the web page is confusing. It does not talk about robustness at all. > >> Since the purpose of PRAMFS is to provide a filesystem > >> that is persistent across kernel instantions, it is not > >> designed for high speed. Robustness in the face of > >> kernel crashes or bugs is the highest priority, so > >> PRAMFS has significant overhead to make the window > >> of writability to the filesystem RAM as small as possible. > > > > Really? So why don't you use well known, reliable fs like ext3? > > Are you sure you read the web site? It directly addresses this > question. From the web site: "1. Disk-based filesystems such as No, it does not. It explains that ext2 would be too slow on this, and explains that it will eat too much disk space. Please back that claims with numbers. If reliability is top concern, explain how you get away w/o journalling. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
On Mon 2009-06-22 14:50:01, Tim Bird wrote: > Pavel Machek wrote: > >> block of fast non-volatile RAM that need to access data on it using a > >> standard filesytem interface." > > > > Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are > > better with ext2. > > Not if you want the RAM-based filesystem to persist over a kernel > invocation. Yes, you'll need to code Persistent, RAM-based _block_device_. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
On Mon 2009-06-22 23:57:53, Pavel Machek wrote: > On Mon 2009-06-22 14:50:01, Tim Bird wrote: > > Pavel Machek wrote: > > >> block of fast non-volatile RAM that need to access data on it using a > > >> standard filesytem interface." > > > > > > Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are > > > better with ext2. > > > > Not if you want the RAM-based filesystem to persist over a kernel > > invocation. > > Yes, you'll need to code Persistent, RAM-based _block_device_. More politely said: "I believe you would be better off modifying ramdisk to include the functionality for persistence." New filesystem should not really be neccessary. ext2 for performance, ext3 if you need robustness from journalling, maybe something else makes sense, too. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
On Tue 2009-06-23 20:07:23, Marco wrote: > Pavel Machek wrote: > > On Mon 2009-06-22 14:50:01, Tim Bird wrote: > >> Pavel Machek wrote: > >>>> block of fast non-volatile RAM that need to access data on it using a > >>>> standard filesytem interface." > >>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are > >>> better with ext2. > >> Not if you want the RAM-based filesystem to persist over a kernel > >> invocation. > > > > Yes, you'll need to code Persistent, RAM-based _block_device_. > > First of all I have to say that I'd like to update the site and make it > clearer but at the moment it's not possible because I'm not the admin > and I've already asked to the sourceforge support to have this possibility. > > About the comments: sincerely I don't understand the comments. We have > *already* a fs that takes care to remap a piace of ram (ram, sram, > nvram, etc.), takes care of caching problems, takes care of write Well, it looks pramfs design is confused. 13MB/sec shows that caching _is_ useful for pramfs. So...? > You are talked about journaling. This schema works well for a disk, but > what about a piece of ram? What about a crazy kernel that write in that > area for a bug? Do you remember for example the e1000e bug? It's not I believe you need both journaling *and* write protection. How do you handle power fault while writing data? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
On Wed 2009-06-24 18:49:11, Marco wrote: > >> Pavel Machek wrote: > >>> On Mon 2009-06-22 14:50:01, Tim Bird wrote: > >>>> Pavel Machek wrote: > >>>>>> block of fast non-volatile RAM that need to access data on it using a > >>>>>> standard filesytem interface." > >>>>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are > >>>>> better with ext2. > >>>> Not if you want the RAM-based filesystem to persist over a kernel > >>>> invocation. > >>> Yes, you'll need to code Persistent, RAM-based _block_device_. > >> First of all I have to say that I'd like to update the site and make it > >> clearer but at the moment it's not possible because I'm not the admin > >> and I've already asked to the sourceforge support to have this possibility. > >> > >> About the comments: sincerely I don't understand the comments. We have > >> *already* a fs that takes care to remap a piace of ram (ram, sram, > >> nvram, etc.), takes care of caching problems, takes care of write > > > > Well, it looks pramfs design is confused. 13MB/sec shows that caching > > _is_ useful for pramfs. So...? > > caching problems means to avoid filesystem corruption, so dirty pages in > the page cache are not allowed to be written back to the backing-store > RAM. It's clear that there is a performance penalty. This penalty should > be reduced by the access speed of the RAM, however the performance are > not important for this special fs as Tim Bird said, so this question is > not relevant for me. If this issue is not clear enough on the web site, > I hope I can update the information in the future. Yes, please update the pages... > >> You are talked about journaling. This schema works well for a disk, but > >> what about a piece of ram? What about a crazy kernel that write in that > >> area for a bug? Do you remember for example the e1000e bug? It's not > > > > I believe you need both journaling *and* write protection. How do you > > handle power fault while writing data? > > Ah now the write protection is a "needed feature", in your previous > comment you talked about why not use ext2/3... write protection should be handled at block device layer, not filesystem layer. So yes, use ext2. You still did not explain how you avoid the need for journalling... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
On Wed 2009-06-24 19:38:37, Marco wrote: > >>> Pavel Machek wrote: > >>>> On Mon 2009-06-22 14:50:01, Tim Bird wrote: > >>>>> Pavel Machek wrote: > >>>>>>> block of fast non-volatile RAM that need to access data on it using a > >>>>>>> standard filesytem interface." > >>>>>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are > >>>>>> better with ext2. > >>>>> Not if you want the RAM-based filesystem to persist over a kernel > >>>>> invocation. > >>>> Yes, you'll need to code Persistent, RAM-based _block_device_. > >>> First of all I have to say that I'd like to update the site and make it > >>> clearer but at the moment it's not possible because I'm not the admin > >>> and I've already asked to the sourceforge support to have this > >>> possibility. > >>> > >>> About the comments: sincerely I don't understand the comments. We have > >>> *already* a fs that takes care to remap a piace of ram (ram, sram, > >>> nvram, etc.), takes care of caching problems, takes care of write > >> Well, it looks pramfs design is confused. 13MB/sec shows that caching > >> _is_ useful for pramfs. So...? > > > > caching problems means to avoid filesystem corruption, so dirty pages in > > the page cache are not allowed to be written back to the backing-store > > RAM. It's clear that there is a performance penalty. This penalty should > > be reduced by the access speed of the RAM, however the performance are > > not important for this special fs as Tim Bird said, so this question is > > not relevant for me. If this issue is not clear enough on the web site, > > I hope I can update the information in the future. > > > >>> You are talked about journaling. This schema works well for a disk, but > >>> what about a piece of ram? What about a crazy kernel that write in that > >>> area for a bug? Do you remember for example the e1000e bug? It's not > >> I believe you need both journaling *and* write protection. How do you > >> handle power fault while writing data? > >>Pavel > > > > Ah now the write protection is a "needed feature", in your previous > > comment you talked about why not use ext2/3... > > > > Marco > > > > Just for your information I tried the same test with pc in a virtual machine > with 32MB of RAM: > > Version 1.03e --Sequential Output-- --Sequential Input- > --Random- > -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- > --Seeks-- > Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec > %CP > hostname 15M:1k 14156 99 128779 100 92240 100 11669 100 166242 99 80058 > 82 > --Sequential Create-- Random > Create > -Create-- --Read--- -Delete-- -Create-- --Read--- > -Delete-- > files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec > %CP > 4 2842 99 133506 104 45088 101 2787 99 79581 101 58212 > 102 > > These data are the proof of the importance of the environment, workload and > so on when we talk > about benchmark. Your consideration are really superficial. Unfortunately, your numbers are meaningless. Pavel (PCs should have cca 3GB/sec RAM transfer rates; and you demosstrated cca 166MB/sec read rate; disk is 80MB/sec, so that's too slow. If you want to prove your filesystem the filesystem is reasonably fast, compare it with ext2 on ramdisk.) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
> >>> If it loses power when doing atomic rename (to replace config files, > >>> for example), it's likely that the whole /pramfs/configs/ directory > >>> will be corrupt, because the rename is writing to the directory inode, > >>> so you lose access to all names in that directory? > >>> > >>> That sounds like it can't be used for persistent configuration data. > >> It's true from this point of view currently there is a lack for this > >> and it needs a bit of effort to resolve this problem. >From this > >> point of view I'd like to point out that I know that there was some > >> aspects to study in a deeper way, so I'll need of more then one > >> review :) but since this fs has been abandoned since 2004 and it > >> hadn't ever reviewed, it was important to do a serious review with > >> the kernel community to understand all the problems. > > > > That's reasonable. > > > > What do you think of my suggestion to double-buffer writes using a > > single fixed position block, as explained elsewhere in this thread? > > > > It should give the power fail safety with very little code. I don't > > know how much it would slwo down writing. That probably depends on > > whether it's the checksum which is slow (which only needs to be done > > once when double-buffering), or the writing. > > Yeah it can be a choice. For this fs it's important to use "simple" but > useful mechanism. What do you exactly mean with "fixed position block"? > A fixed position in the fs? For example superblock+inodetable+in-use > bitmap+blocks+"double-buffering block"? Using a temp block of the same > size of blocks used, isn't it? I agree, but I think it needs more then > 100 lines of code. Even with this simple schema it needs a mechanism > with a timeout to do the "commit" of the temp block, it needs a > mechanism to read the temp block instead of the "old" block or a > mechanism to write-back the temp block. So it can be implemented but it > needs a bit of effort. I think I'll implement it in the next release. I think you should really use ext3 over special block device. Initially this filesystem was presented as fast (it is not) then you claim it is reliable (it is not). If you want it to get reliable you'll need journalling+fsck. Good luck. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
> >> > Ah now the write protection is a "needed feature", in your previous > >> > comment you talked about why not use ext2/3... > >> > > >> > Marco > >> > > >> > >> Just for your information I tried the same test with pc in a virtual > >> machine with 32MB of RAM: > >> > >> Version 1.03e --Sequential Output-- --Sequential Input- > >> --Random- > >> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- > >> --Seeks-- > >> Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP > >> /sec %CP > >> hostname 15M:1k 14156 99 128779 100 92240 100 11669 100 166242 99 > >> 80058 82 > >> --Sequential Create-- Random > >> Create > >> -Create-- --Read--- -Delete-- -Create-- --Read--- > >> -Delete-- > >> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > >> /sec %CP > >> 4 2842 99 133506 104 45088 101 2787 99 79581 101 > >> 58212 102 > >> > >> These data are the proof of the importance of the environment, workload > >> and so on when we talk > >> about benchmark. Your consideration are really superficial. > > > > Unfortunately, your numbers are meaningless. > > I don't think so. > > > (PCs should have cca 3GB/sec RAM transfer rates; and you demosstrated > > cca 166MB/sec read rate; disk is 80MB/sec, so that's too slow. If you > > want to prove your filesystem the filesystem is reasonably fast, > > compare it with ext2 on ramdisk.) > > > This is the point. I don't want compare it with ext2 from performance > point of view. This comparison makes no sense for me. I've done this > test to prove that if you change environment you can change in a > purposeful way the results. Yes, IOW you demonstrated that the numbers are machine-dependend and really meaningless. ext2 comparison would tell you how much pramfs sucks (or not). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
On Sun 2009-06-28 19:33:02, Marco Stornelli wrote: > Pavel Machek wrote: > >>>>> Ah now the write protection is a "needed feature", in your previous > >>>>> comment you talked about why not use ext2/3... > >>>>> > >>>>> Marco > >>>>> > >>>> Just for your information I tried the same test with pc in a virtual > >>>> machine with 32MB of RAM: > >>>> > >>>> Version 1.03e --Sequential Output-- --Sequential Input- > >>>> --Random- > >>>> -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- > >>>> --Seeks-- > >>>> Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP > >>>> /sec %CP > >>>> hostname 15M:1k 14156 99 128779 100 92240 100 11669 100 166242 99 > >>>> 80058 82 > >>>> --Sequential Create-- Random > >>>> Create > >>>> -Create-- --Read--- -Delete-- -Create-- --Read--- > >>>> -Delete-- > >>>> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > >>>> /sec %CP > >>>> 4 2842 99 133506 104 45088 101 2787 99 79581 101 > >>>> 58212 102 > >>>> > >>>> These data are the proof of the importance of the environment, workload > >>>> and so on when we talk > >>>> about benchmark. Your consideration are really superficial. > >>> Unfortunately, your numbers are meaningless. > >> I don't think so. > >> > >>> (PCs should have cca 3GB/sec RAM transfer rates; and you demosstrated > >>> cca 166MB/sec read rate; disk is 80MB/sec, so that's too slow. If you > >>> want to prove your filesystem the filesystem is reasonably fast, > >>> compare it with ext2 on ramdisk.) > >>> > >> This is the point. I don't want compare it with ext2 from performance > >> point of view. This comparison makes no sense for me. I've done this > >> test to prove that if you change environment you can change in a > >> purposeful way the results. > > > > Yes, IOW you demonstrated that the numbers are machine-dependend and > > really meaningless. > > > > ext2 comparison would tell you how much pramfs sucks (or not). > > Here the test with ext2 (same environment): > > Version 1.03e --Sequential Output-- --Sequential Input- > --Random- > -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- > --Seeks-- > Machine Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec > %CP > hostname 15M:1k 10262 83 40847 82 38574 82 9866 92 62252 98 25204 > 81 > --Sequential Create-- Random > Create > -Create-- --Read--- -Delete-- -Create-- --Read--- > -Delete-- > files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec > %CP > 1 19859 98 44804 61 68830 100 13566 99 157129 100 30431 > 98 > Ok, so pramfs is significantly faster than ext2. Interesting, and good for pramfs. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [POWER] battery calibration parameters from sysfs
> One of the things we're facing is Android, which has > its userspace in plain Java JNI at the end of this link: > http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=s > ervices/jni/com_android_server_BatteryService.cpp;h=8e7cadc6b680fc420d34 > 1faa094c71922946fdab;hb=HEAD > > If you browse down to line 275 you can see it parse the sysfs > attribute "capacity", then this propagates up to the battery > status indicator on *all* Android phones out there. So if > you want to run Android unmodified, this is what you need to > provide. They are effectively using the power sysfs as > their hardware abstraction layer in this case. > > Note: I'm not claiming that Android is doing it right or that > we can't modify this code or so, it's just that this is the way > a few million Android devices out there are actually doing it. Users can't modify them, so they don't count... ...but then there are all the systems that rely on /proc/apm emulation, like openembedded popular on sharp zaurus... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [POWER] battery calibration parameters from sysfs
Hi!
> > If you browse down to line 275 you can see it parse the sysfs
> > attribute "capacity", then this propagates up to the battery
> > status indicator on *all* Android phones out there. So if
> > you want to run Android unmodified, this is what you need to
> > provide. They are effectively using the power sysfs as
> > their hardware abstraction layer in this case.
>
> Oh dear. Using the power sysfs as the hardware abstraction seems
> perfectly reasonable but assuming that a given battery driver is going
> to have this level of information doesn't match up with an awful lot of
> actual charger hardware. My main concern here is that battery
> performance monitoring has no pressing need to be in kernel and that
> pushing it into the kernel creates a barrier to implementing more
> advanced schemes in userspace, which is especially serious given how
> involved this needs to be in order to be accurate.
Well, kernel provides /proc/apm emulation and many systems still rely
on it. So it would be nice to provide something halfway-decent there.
Plus you need to shutdown/suspend machine on battery critical. That
has to be in kernel and already needs those tricky parts.
(Sharp got it wrong in collie kernel, and you get 5hours instead of 10
with old battery :-(().
> I'm not sure how familiar you are with the issues surrounding trying to
> do a voltage to charge mapping for a battery but it's much more complex
> than a simple table if you want to get it accurate. There's a lot
> of
Well... current zaurus kernels use _huge_ table that maps voltage to
battery %... and that table is linear function :-(.
Do you have some papers on that?
> dependence on particular operating conditions and things do change as
> the batteries age. There are systems out there that do the work
> required to gather the information in hardware and it's definitely good
> to report the information from them but that doesn't mean it's a good
> idea to try to synthesise the information for other systems.
So... on zaurus I plan to:
1) provide better voltage -- %age map
2) estimate current
3) estimate internal battery resistance as constant
4) estimate internal battery volltage using ohm's law and base %age
estmate on that.
Now... I realize that internal resistance depends on charge left. Nasty
but probably can be ignored. Then it depends on temperature. Does
anyone have better idea how?
Then... I need a way to measure internal resistance. I know it is in
200mOhm to 400mOhm range, on my device. Is there easy way to measure
it more accurately?
Pavel
#!/bin/bash
#
# Copyright 2009 Pavel Machek , GPLv2
#
getval() {
SETTLETIME=5
echo Run this on idle, unplugged system, with expansion cards
echo removed and backlight enabled
echo
echo 1 > /sys/class/backlight/corgi?bl/brightness
echo Backlight 1, waiting for power to settle
sleep $SETTLETIME
VBMIN=`cat /sys/class/power*/*battery/voltage_now`
VBMIN=$[$VBMIN/1000]
echo Voltage = $VBMIN mV
echo
echo 47 > /sys/class/backlight/corgi?bl/brightness
echo Backlight 47, waiting for power to settle
sleep $SETTLETIME
VBMAX=`cat /sys/class/power*/*battery/voltage_now`
VBMAX=$[$VBMAX/1000]
echo Voltage = $VBMAX mV
echo 1 > /sys/class/backlight/corgi?bl/brightness
}
fake1() {
# Very old 1000mAh battery from collie: 703 mOhm
VBMIN=3638
VBMAX=3543
}
fake2() {
# Old 2000mAh battery, nearly charged, 4C: 274 mOhm
VBMIN=3732
VBMAX=3695
}
fake3() {
# Same old 2000mAh battery, nearly charged, 4C: 140 mOhm
# temp: 155.
VBMIN=3714
VBMAX=3695
# Next try: temp 151 -- little warmer: 422 mOhm.
# Next try: temp 151 -- little warmer: 1266 mOhm.
# Next try: temp 148 -- getting warmer: 281 mOhm.
# Next try: temp 148 -- getting warmer, full load: 422 mOhm.
# Next try: temp 148 -- getting warmer, full load: 140 mOhm.
# Next try: temp 148 -- getting warmer, full load: 422 mOhm.
# Next try: temp 138 -- getting warmer, full load: 422 mOhm.
# Next try: temp 139 -- getting warmer, full load: 422 mOhm.
# Next try: temp 136 -- getting warmer, full load: 562 mOhm.
# Next try: temp 132 -- getting warmer, full load: 703 mOhm.
# Next try: temp 132 -- getting warmer, full load: 281 mOhm.
# Next try: temp 134 -- getting warmer, full load: 281 mOhm.
# Next try: temp 134 -- getting warmer, full load: 562 mOhm.
# Next try: temp 129 -- getting warmer, full load: 562 mOhm.
# hugh, I''m getting n*140, wtf?
# ...voltmeters have sensitivity limits...
# temp 118 -- metro, venku zima -- full load: 281 mOhm.
# temp 118 -- metro, venku zima, baterie poloprazdna -- full load: 281 mOhm.
# temp 120 -- metro, venku zima, b
Re: [POWER] battery calibration parameters from sysfs
On Mon 2009-12-14 11:50:24, Mark Brown wrote: > On Sun, Dec 13, 2009 at 02:19:22PM +0100, Pavel Machek wrote: > > > ...but then there are all the systems that rely on /proc/apm > > emulation, like openembedded popular on sharp zaurus... > > OpenEmbedded is a meta-distribution so doesn't use any particular > software here - I suspect you're referring to things like the GPE stack > which isn't so actively developed these days. Both Opie and GPE have the problem IIRC... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [POWER] battery calibration parameters from sysfs
Hi! > > > I'm not sure how familiar you are with the issues surrounding trying to > > > do a voltage to charge mapping for a battery but it's much more complex > > > than a simple table if you want to get it accurate. There's a lot > > > of > > > Well... current zaurus kernels use _huge_ table that maps voltage to > > battery %... and that table is linear function :-(. > > > Do you have some papers on that? > > Something like "Measure Battery Capacity Precisely in Medical Design" > by Bernd Krafthoefer in Power Electronics Technology Jan 2005 might be > useful here. Well, that would really require extensive hardware modifications: it needs _way_ more accurate ADCs on battery for a start, and a way to generate huge load. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [POWER] battery calibration parameters from sysfs
On Mon 2009-12-14 12:12:47, Mark Brown wrote: > On Sun, Dec 13, 2009 at 02:24:14PM +0100, Pavel Machek wrote: > > > > actual charger hardware. My main concern here is that battery > > > performance monitoring has no pressing need to be in kernel and that > > > pushing it into the kernel creates a barrier to implementing more > > > advanced schemes in userspace, which is especially serious given how > > > involved this needs to be in order to be accurate. > > > Well, kernel provides /proc/apm emulation and many systems still rely > > on it. So it would be nice to provide something halfway-decent there. > > Unfortunately that's really painful in kernel since you really need to > do state tracking over reboots, and even if you do that it's really > not trivial. No, I do not want to get _that_ advanced. But I'd really like to get beyond "battery %age is linear function of measured battery voltage". > > Plus you need to shutdown/suspend machine on battery critical. That > > has to be in kernel and already needs those tricky parts. > > Power failure detection based on voltage drop is much more reasonable > but it's a very different thing to general battery capacity > estimation. Not sure... > Normally you'd want to do the power failure detection separately anyway, > monitoring the system supply voltage rather than the battery voltage. Well, that way you'll discharge batteries too much and kill them rather quickly, no? What is "system supply voltage" for PDA class system, anyway? I don't think zaurus has ADCs on anything else than thermistor, AC in voltage, battery voltage... > Something like "Measure Battery Capacity Precisely in Medical Design" > by Bernd Krafthoefer in Power Electronics Technology Jan 2005 might be > useful here. Thanks, it looks interesting. I'm not sure if it will be possible to apply on zaurus, but... (While measuring voltage my underestimate the old battery, I'm afraid they may overestimate it in bad conditions; energy left is battery is useless if battery can't supply enough current to keep CPU happy, because its too cold). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [POWER] battery calibration parameters from sysfs
Hi!1 >>> Yes, but in that case you might as well just purchase a coulomb >>> counter with a built-in accumulator and an I2C/SPI/microwire interface >>> save yourself some PCB space and cost (maybe) Hardware is already given. >> Well, Pavel attempts to implement a "poor man's Coulomb counter" or at >> least "poor man's Ampere meter" for devices that are not equipped with >> any of it. > > I think the "poor man's Coulomb counter" is a loser, the errors will > overwhelm you too rapidly. The estimated rate of discharge could >> work, Actually android phones do "poor man's Coulomb counter", and it seems to mostly work. > based on what clocks, regulators and so on are running, but I am not > sure how useful that number is really given you can't realistically > integrate it due to the big error it is bound to have. ... > Otherwise for L-ion batteries, looking at the voltage level alone, > filtered to remove GSM transmit slots etc, is really quite workable for > estimating charge status. Well, you have to compensate for backlight power; and yes, that's what I'm trying to do. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
Hi! > +Challenges > + > +One of the difficulties in implementing a generic PWM framework is the > +fact that pulse-width-modulation applications involve real-world > +signals, which often must be carefully managed to prevent destruction > +of hardware that is linked to those signals. A DC motor that > +experiences a brief interruption in the PWM signal controlling it > +might destructively overheat; it could suddenly change speed, losing > +synchronization with a sensor; it could even suddenly change direction > +or torque, breaking the mechanical device connected to it. Stop right here. Linux is not hard realtime os, nor is it an os that never crashes. > +(A generic PWM device framework is not directly responsible for > +preventing the above scenarios: that responsibility lies with the > +hardware designer, and the application and driver authors. But it Exactly; if your hw can be damaged by software, it was misdesigned. Is the paragraph #1 really neccessary? > +Using the API to Generate PWM Signals -- Basic Functions for Users > + > + > +pwm_request() -- Returns a pwm_channel pointer, which is subsequently > +passed to the other user-related PWM functions. Once requested, a PWM > +channel is marked as in-use and subsequent requests prior to > +pwm_free() will fail. > + > +The names used to refer to PWM devices are defined by driver authors. > +Typically they are platform device bus identifiers, and this > +convention is encouraged for consistency. > + > + > +pwm_free() -- Marks a PWM channel as no longer in use. The PWM device > +is stopped before it is released by the API. free is normally used for something else. Rename to open/close? > +pwm_start(), pwm_stop() -- Turns the PWM signal on and off. Except > +where stated otherwise by a driver author, signals are stopped at the > +end of the current period, at which time the output is set to its > +inactive state. What does it mean to stop a signal? What is the difference between 0% duty cycle and stop() ? > +pwm_polarity() -- Defines whether the PWM signal output's active > +region is "1" or "0". A 10% duty-cycle, polarity=1 signal will > +conventionally be at 5V (or 3.3V, or 1000V, or whatever the platform > +hardware does) for 10% of the period. The same configuration of a > +polarity=0 signal will be at 5V (or 3.3V, or ...) for 90% of the > +period. Is polarity realy required? Can't driver just replace duty with 100%-duty? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
> +static void
> +gpio_pwm_work (struct work_struct *work)
> +{
> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
> +
> + if (gp->active)
> + gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
> + else
> + gpio_direction_output(gp->gpio, gp->polarity ? 0 : 1);
> +}
...polarity ^ active ?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
On Thu 2010-02-11 14:35:14, Bill Gatliff wrote:
> Pavel Machek wrote:
> >> +static void
> >> +gpio_pwm_work (struct work_struct *work)
> >> +{
> >> + struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
> >> +
> >> + if (gp->active)
> >> + gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
> >> + else
> >> + gpio_direction_output(gp->gpio, gp->polarity ? 0 : 1);
> >> +}
> >>
> >
> > ...polarity ^ active ?
> >
>
> ... except that if polarity and/or active are >1, I don't send the
> values 1 or 0 to gpio_direction_output. I don't know if the API is
> specifically intended to accept nonzero values that are greater than 1.
!polarity ^ !active ? :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
> >> +pwm_free() -- Marks a PWM channel as no longer in use. The PWM device > >> +is stopped before it is released by the API. > >> > > > > free is normally used for something else. Rename to open/close? > ... or request/release? Works for me. > >> +pwm_start(), pwm_stop() -- Turns the PWM signal on and off. Except > >> +where stated otherwise by a driver author, signals are stopped at the > >> +end of the current period, at which time the output is set to its > >> +inactive state. > >> > > > > What does it mean to stop a signal? What is the difference between 0% > > duty cycle and stop() ? > > > > Depends on the hardware. For a true PWM peripheral, a 0% duty cycle > might still have the base peripheral clock for the device running. > Whereas a pwm_stop() signal could be used to turn off the clock to the > peripheral. If it is just powersaving... I'd do it automatically when 0% duty is selected...? Or is that infeasible due to latency...? > > Is polarity realy required? Can't driver just replace duty with > > 100%-duty > > Actually, yes in some cases. Users can always do the 100%-duty math, > but some hardware asserts a specific output state when you stop the > peripheral that's potentially different from 0% duty. Also, some > hardware begins the PWM cycle with the output high, while others do with > the output low. It isn't necessarily the case that the user cares, but > I was thinking that having the API allow for different polarity might > prevent some applications having to optionally do the %duty vs. > 100-%duty conversion themselves. Ok, ok, but this should go into the docs. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
>
> 11.02.2010, ? 23:58, Pavel Machek ???(?):
>
> > On Thu 2010-02-11 14:35:14, Bill Gatliff wrote:
> >> Pavel Machek wrote:
> >>>> +static void
> >>>> +gpio_pwm_work (struct work_struct *work)
> >>>> +{
> >>>> +struct gpio_pwm *gp = container_of(work, struct gpio_pwm, work);
> >>>> +
> >>>> +if (gp->active)
> >>>> +gpio_direction_output(gp->gpio, gp->polarity ? 1 : 0);
> >>>> +else
> >>>> +gpio_direction_output(gp->gpio, gp->polarity ? 0 : 1);
> >>>> +}
> >>>>
> >>>
> >>> ...polarity ^ active ?
> >>>
> >>
> >> ... except that if polarity and/or active are >1, I don't send the
> >> values 1 or 0 to gpio_direction_output. I don't know if the API is
> >> specifically intended to accept nonzero values that are greater than 1.
> >
> > !polarity ^ !active ? :-).
>
>
> One the one hand that wouldn't be 100% right because according to
> ANSI C !(0) is just != 0 but no one says it is 1.
I believe you are wrong here.
!!x is common idiom using to turn anything into 0/1, used all over kernel.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/16 v5] pramfs: documentation
Hi! > +But the disk-based fs over non-volatile RAM block driver approach has > +some drawbacks: > + > +1. Complexity of disk-based fs: disk-based filesystems such as ext2/ext3/ext4 > + were designed for optimum performance on spinning disk media, so they > + implement features such as block groups, which attempts to group inode > data > + into a contiguous set of data blocks to minimize disk seeking when > accessing > + files. For RAM there is no such concern; a file's data blocks can be Yes, and they are also used on 99% of machines out there -> well debugged. Is there fsck for pramfs available, for example? > + This increases the efficient use of space on the media, i.e. more > + space is dedicated to actual file data storage and less to meta-data > + needed to maintain that file data. So... how big is overhead of pramfs compared to ext2? Can pramfs handle powerdown at arbitrary time? -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/17] pramfs: documentation
> On 07/01/2011 22:59, Tony Luck wrote: > > On Fri, Jan 7, 2011 at 12:30 PM, Marco Stornelli > > wrote: > >> constraint). About the errors: pramfs does not maintain file data in the > >> page caches for normal file I/O, so no writeback, the read/write > >> operation are done with direct io and they are always sync. The data are > >> write protected in hw when the arch provide this facility (x86 does). > >> Inode contains a checksum and when there are problems they are marked as > >> bad. Superblock contains checksum and there is a redundant superblock. > > > > But you can still get pramfs inconsistencies if the system crashes at an > > inopportune moment. E.g. when making files you write the new inode to > > pramfs, and then you insert the entry into the directory. A crash between > > these two operations leaves an allocated inode that doesn't appear in > > any directory. Without a fsck option, it will be hard to see that you have > > this problem, and your only recovery option is to wipe *all* files by making > > a new filesystem. > > Is it a problem if you lost some logs? However do you expect that fsck > in this case will drop the inode? Ask it the other way around. What is persistent filesystem good for when it is only persistent sometimes? You'd be better running ext2 over special block device, it is quite simple. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/17] pramfs: persistent and protected RAM filesystem
> Il 06/01/2011 19:22, Luck, Tony ha scritto: > >> Errata corrige: maybe I used the wrong term, I meant "volatile" instead > >> of "temporary" information, i.e. I'd like to save this info to re-read > >> it later but I don't want to store it in flash, a simple log, run-time > >> information for debug like a flight-recorder or whatever you want. > > > > I'm puzzled by the use of "a generic piece of memory" to store "persistent" > > things (Perhaps this is made clear in the 17 parts of the patch? I haven't > > read them yet). On x86 f/w typically clears all of memory on reset ... so > > you only get persistence if you use kexec to get from the old kernel to > > the new one. > > > > -Tony > > > > First of all, you can find a lot of information on the web site where > there is an overview and a page with implementation details, benchmark > and so on. With "a generic piece of memory" I mean a generic memory > device directly addressable. Usually this generic device is an NVRAM, so > we have a persistent store. If you haven't got this hw you can use other > devices or the classic RAM, in this case you have a fs persistent only > over reboot. The use of this fs is mainly for embedded systems, fw can > be configured to not clear *all* the memory. Pramfs is indeed supported > by U-Boot, you can see CONFIG_PRAM in the Das U-Boot manual. x86 in this > case can be a "strange" world for this fs, but however if the user wants > it can be used without problems because there aren't neither strict arch > or hw dependency. Actually you probably want to state u-boot compatibility in the commit message. AFAICT, that is quite good argument _for_ inclusion. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM: Hide CONFIG_PM from users
Hi! > It is very rare to find a current system which is both sufficiently > resource constrained to want to compile out power management support > and sufficiently power insensitive to be able to tolerate doing so. Ok, how much memory do we talk about here? Lots of embedded systems are AC powered or powered from some powerful source -- such as alternator in car. PM can be unwanted complexity there. Ot maybe they are running under realtime hypervisor... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
