original kernel

This forum is for all other ARMv5 devices

Re: original kernel

Postby kmihelich » Sat Jun 18, 2011 5:19 pm

There is no difference to Linux between a file and a partition. Linux does not treat files in the same single-minded user-data-store idea you may be accustomed to on Windows. A "file" can be a whole range of different "things." The way you access a partition, say /dev/sda1, that's a file. There are more thorough explanations out there on the internet.

The reason you don't put swap on flash is because flash sucks at random I/O. There are benchmarks everywhere to prove this if you haven't already felt this in practice. Swap space is a RAM substitute, RAM of course standing for Random Access Memory.. again: flash sucks at random I/O. Given that flash chokes on random access, if you do enough of it it will get backlogged to the point of the system becoming unresponsive -- especially if your swap is on the same drive as your OS. USB and flash combined create a black hole of nothing happening when this situation arises. Using sata and a fast spinning disk, not so much of an issue. Hard drives excel at random access, that's one of the things they were designed to handle. Flash was designed for sequential read/write, and manufacturers constantly try to improve this. For instance, higher SD card classes represent faster sequential write speed -- an important issue in their targeted market of dSLR cameras that are filling them up with tens of megabytes per second worth of image data.
Arch Linux ARM exists and continues to grow through community support, please donate today!
kmihelich
Developer
 
Posts: 1132
Joined: Tue Jul 20, 2010 6:55 am
Location: aka leming #archlinux-arm

Re: original kernel

Postby Cybertimber2009 » Sat Jun 18, 2011 6:33 pm

kmihelich wrote:The reason you don't put swap on flash is because flash sucks at random I/O. There are benchmarks everywhere to prove this if you haven't already felt this in practice.

??? Link? I thought flash excelled at random IO because there isn't a mechanical delay? I mean that's the whole point behind the SSD movement? And ReadyBoost, etc. Wear and tear understood yea... but sucking at Random IO?

http://www.datacenterpost.com/2011/06/t ... emory.html
Flash excels at random I/O performance, offering greater than 10x gains in I/Os per second (IOPS); flash has no seeking, no rotational latency, and performs equally well on random workloads as it does on sequential ones.


http://www.purestorage.com/why-flash/
...oh hey, they plagarized... either PureStorage wrote the above, or datacenterpost did, but they say the same thing, verbatium
Random I/O performance
Flash excels at random I/O performance, offering greater than 10x gains in I/Os per second (IOPS). Flash has no seeking, no rotational latency, and performs equally well on random workloads as it does on sequential ones.


Regardless, wouldn't swap, especially a swap file, be typically a large chunk of data? I mean... I haven't seen *any* swap usage what-so-ever yet... but this is good to know and discuss still.
Cybertimber2009
 
Posts: 40
Joined: Wed Jun 08, 2011 9:17 pm

Re: original kernel

Postby kmihelich » Sat Jun 18, 2011 7:09 pm

What you're quoting is the type of flash used in SSDs, which is of course much better at random I/O. Your thumb drive is not an SSD. Dig deeper than the first links on Google, especially on such a broad query.

Not only will swapping to the same USB drive as your OS be compounded by the fact that it's a thumb drive, that I/O is now fighting with the rest of your system trying to read/write data from that same USB device. You can see this visually running 'top':
Code: Select all
Cpu(s): 25.6%us, 33.5%sy,  0.0%ni, 40.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st


That indicates how the processor is being used. Of interest for this conversation is the 'wa' value that represents system IO wait. This is the percentage of CPU cycles that are spent waiting for disk events (network events as well). Deliberately start something that will use up your RAM and start swapping, then watch that number. Or just extract a tarball and notice the differences between a flash drive and a spinning disk. Further, notice the difference between a USB drive and one connected via SATA. The fact that a swap file is just a large block of data has nothing to do with it. Underneath what you see at the user level, that file is still spanning a large number of blocks, which are what are acted upon when writing data.
Arch Linux ARM exists and continues to grow through community support, please donate today!
kmihelich
Developer
 
Posts: 1132
Joined: Tue Jul 20, 2010 6:55 am
Location: aka leming #archlinux-arm

Re: original kernel

Postby kleiner » Sun Jun 19, 2011 10:26 am

Which .config file do you use (.config~ or .config.old)?

I guess i got the same error when i took the .config~. I take the .config.old and i'm able to compile and boot my own uImage based on sources from pogoplug.com and the modification from WarheadsSE.

tritron wrote:I wonder if anyone can upload original kernel image. I had installed debian on usb drive and it installed newer kernel and now my pogoplug pro will not boot. It was working fine with original kernel. I hope I can find download for it and use my linux box to push it to usb drive. i had tried to compile kernel but I get errors
tmp_vmlinux1
drivers/built-in.o: In function `hwraid1_sync_request':
ox820hwraid.c:(.text+0x7c870): undefined reference to `raid1_lower_barrier'
drivers/built-in.o: In function `sync_work':
ox820hwraid.c:(.text+0x7ccbc): undefined reference to `raid1_lower_barrier'
ox820hwraid.c:(.text+0x7ce4c): undefined reference to `raid1_lower_barrier'
drivers/built-in.o: In function `post_sync_write':
ox820hwraid.c:(.text+0x7cf20): undefined reference to `raid1_lower_barrier'
make: *** [.tmp_vmlinux1] Error 1
root@aphrodite:/usr/src/pogopro-linux-2.6.31.6-r2# make menuconfig
scripts/kconfig/mconf arch/arm/Kconfig
kleiner
 
Posts: 11
Joined: Thu Jun 02, 2011 8:05 pm

Re: original kernel

Postby tritron » Sun Jun 19, 2011 1:06 pm

I had this solved by enabling all options under sata drivers 820 section. Just say yes to all options.
tritron
 
Posts: 83
Joined: Thu Jun 16, 2011 7:16 pm

Re: original kernel

Postby WarheadsSE » Sun Jun 19, 2011 1:08 pm

Thats pretty much it
Core Developer
Remember: Arch Linux ARM is entirely community donation supported!
WarheadsSE
Developer
 
Posts: 6807
Joined: Mon Oct 18, 2010 2:12 pm

Re: original kernel

Postby kleiner » Sun Jun 19, 2011 1:43 pm

No i have another problem with my own uImage.

The pogoplug doesn't reset while rebooting, the reboot process will stuck as shown on picture.

Does anybody know a solution for this problem?

reboot.jpg
reboot.jpg (43.89 KiB) Viewed 5241 times
kleiner
 
Posts: 11
Joined: Thu Jun 02, 2011 8:05 pm

Previous

Return to Community Supported

Who is online

Users browsing this forum: No registered users and 1 guest