Introducing chromeos-kernel-next

[Olof Johansson]

We've created a new ebuild, chromeos-kernel-next, to make it easier to build and use a kernel tree that is tracking closer to mainline than our current 2.6.32-based one.  We want to make it easy for people who want to give it a try to get some runtime on it without jumping through too many hoops to build it.

To build it by default for your system, add "--profile=kernel-next" to setup_board (this exists only for tegra2 and x86-generic/pineview at the moment). This will replace the default kernel for your board with the one from kernel-next. It's the default for tegra today, x86 still uses the previous kernel sources by default.

Feel free to give it a go, and let us know of any problems. Functionally it should be more or less equivalent to the 2.6.32 kernel (i.e. everything should work), but there could be exceptions. In general we're trying to stay close to mainline and will rebase onto a new branch every few weeks (it's currently at 2.6.35 and overdue for a .36-rc rebase).

Two known issues so far is that boot times are quite a bit slower, and there are a couple of suspend/resume bugs.

Right now I have manually been porting over changes from the .32 tree to kernel-next, so there's no need to submit separate CLs for the new tree unless you want to.

-Olof

[Jonathan Kliegman]

Thanks for the instructions Olof.

If we're looking to do some development against it on a different overlay not mentioned are there any specific steps or configuration we should do?  Specifically the right way to sync the new kernel files and to make sure the configurations in make.conf are still valid?  The last sync we did for kernel-next didn't have the chromeos/config directory so we've been seeing some problems.

-Jon

--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Olof Johansson]

There's a chromeos/config directory now (I had messed up the merge-over of the contents from the previous kernel, kwaters pointed it out for me earlier this week and I fixed it up). Let me know if you see any problems still.

The only thing you need to do to add it to a new overlay is to enable it in profiles. See under trunk/src/overlays/overlay-x86-generic/profiles to see how it's setup (it's just selecting a different provider for virtual/kernel).

-Olof

[Sean Paul]

I don't see it yet, should I?

Sean

[Olof Johansson]

http://git.chromium.org/cgi-bin/gitweb.cgi?p=kernel-next.git;a=tree;f=chromeos/config;h=6d566e74929d68695e4f40b047e3fe79faf1a835;hb=refs/heads/chromeos-2.6.35

Note that we are not working on the master branch of kernel-next.git. We're working on chromeos-2.6.35, which is what repo should be downloading for you.

-Olof

[Sean Paul]

Looks like there's a bug in cros_workon, it was pulling from master.

I've filed a bug to track: http://code.google.com/p/chromium-os/issues/detail?id=6811

Thanks for your help,

Sean

[Rudolf Kutina (VirtGuru)]

Hi Olof,

I have Aton N330+Ion and Atom D510 pineview systems, so I am interested if new kernel can bring me:

- SSD disk trim support
- Nvidia Ion support with VGA nouveau and NET forcedev
- Nvdia Ion 2 Optimus support with VGA nouveau

Nice day
Rudolf

> ------------ Původní zpráva ------------
> Od: Olof Johansson <ol...@google.com>
> Předmět: [cros-dev] Introducing chromeos-kernel-next
> Datum: 16.9.2010 23:50:48
> ----------------------------------------

> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>
>
>

12 Minutes with Chromium OS http://wp.me/PLojB-id

[Olof Johansson]

Hi,

On Sat, Sep 18, 2010 at 11:13 AM, Rudolf Kutina (VirtGuru) <em...@post.cz> wrote:

Hi Olof,

I have Aton N330+Ion and Atom D510 pineview systems, so I am interested if new kernel can bring me:

 - SSD disk trim support
 - Nvidia Ion support with VGA nouveau and NET forcedev
 - Nvdia Ion 2 Optimus support with VGA nouveau

The source is available, it's easy to build and try it out yourself. I suggest you give it a go, and if something is missing or broken, submit patches to fix it.

Thanks,

-Olof

[Grant Grundler]

On Sat, Sep 18, 2010 at 9:13 AM, Rudolf Kutina (VirtGuru) <em...@post.cz> wrote:
> Hi Olof,
>
> I have Aton N330+Ion and Atom D510 pineview systems, so I am interested if new kernel can bring me:
>
>  - SSD disk trim support

TRIM command is supported by the libata stack in 2.6.35.

But you'll also need a file system that issues trim commands and an
SSD with firmware that can grok TRIM command. AFAIK, only the most
recent ones do. (Past 6 months or so? Don't know exactly)

Last I heard, ext4 could issue TRIM commands but it wasn't quite ready
for prime yet. I've not tested it myself so this is second hand info.

hth,
grant

[Rudolf Kutina (VirtGuru)]

Hi Grant,

> ------------ Původní zpráva ------------
> Od: Grant Grundler <grun...@chromium.org>
> Předmět: Re: [cros-dev] Introducing chromeos-kernel-next
> Datum: 20.9.2010 05:28:17
> ----------------------------------------

> On Sat, Sep 18, 2010 at 9:13 AM, Rudolf Kutina (VirtGuru) <em...@post.cz>
> wrote:
> > Hi Olof,
> >
> > I have Aton N330+Ion and Atom D510 pineview systems, so I am interested if new
> kernel can bring me:
> >
> > - SSD disk trim support

Looks like then Chromium OS (Chrome OS) count with SSD disk usage deeper then then I originally though,
and TRIM (may be even newer disks with proactive Garbage Collectors) can be at the and essential part of devices.
Chrome OS design don't use swap and also looks then RAM is not massively used for caching (nor or OS-FS level,
nor on Web Browesr level). Looks current design simply count then SSD disk is fast enough without degradations.

So it will be helpful to more considering and documeting used (needed) SSD features like:
- format aligments (Allready imlementd, but not documented well in disk format doc)
- TRIM + Background Garbage Collection (preventing performance degradation over time )
- Transparent compression on latest SandForce chips (we use a lot of not compressible images)

Experience: I upgrade from single core N230/1GB to dual core D510/1GB and later to dual core D510/2GB,
no performance improvements perceived using USB disk with adding more 1GB RAM ?

>
> TRIM command is supported by the libata stack in 2.6.35.
>
> But you'll also need a file system that issues trim commands and an
> SSD with firmware that can grok TRIM command. AFAIK, only the most
> recent ones do. (Past 6 months or so? Don't know exactly)
>

Generally, it depend of used controller SSD and if ti has updated firmware in controller:
For simplification only cheaper MLC disks are considered:
(Wee OZC is know to give samples for projects they interested in):

Entry (Value) level disks
- JMicron JMF602 (64MB cache), have issue with jittering/stuttering problem, TRIM ?
- Toshiba clone of JMF602 SNVP225, TRIM ?
- Samsung RBBxxx, Trim with upgrade (SSD Samsung, Corsair P series, OCZ Summit series, Kingston V+ first generation)
- Indilinx Amigos , TRIM YES

Mainstream:

- Today mainly Indilinx IDX110M00-FC "Barefoot", TRIM added in firmware updates and also tune up utility added
- Thoshiba Toshiba T6UG1XBG, TRIM YES
- JMicron JMF612, JMF618 (some have 128MB cache), TRIM mostly with firmware upgrade
- Marvell 88SS9174-BJP2, TRIM mostly with firmware upgrade
- Intel controllers Intel PC29Axxx like supports TRIM (Intell X25-V, Kingston M series)

Perfomance series:

New Sandforce SF-1x00 have TRIM and Garbage Collectors from first release,
but it also have magic transparent compressions (up to 1:2), so it allow to use a slower (cheaper MLC chips),
2 categories of disk
- with 10000-15000 IOPS OCZ VERTEX 2 series
- with 50000 IOPS OCZ Agility 2 series

> Last I heard, ext4 could issue TRIM commands but it wasn't quite ready
> for prime yet. I've not tested it myself so this is second hand info.
>

TRIM support in ext4 is called "batched discard support" and looks its allready backported (merged) to ext3 ?

http://www.listware.net/201007/linux-ext4/18682-ext4-batched-discard-support-simplified-version.html

http://www.listware.net/201007/linux-ext4/19765-ext3-batched-discard-support.html

http://www.listware.net/201007/linux-ext4/101684-patch-03-v3-batched-discard-support-for-ext3ext4.html

Only I am afraid what happen if FS is mounted with "-o discard" paramemter on real or virtual non SSD disk.

R.

[Grant Grundler]

On Mon, Sep 20, 2010 at 12:30 AM, Rudolf Kutina (VirtGuru)

<em...@post.cz> wrote:
> Hi Grant,
>
>> ------------ Původní zpráva ------------
>> Od: Grant Grundler <grun...@chromium.org>
>> Předmět: Re: [cros-dev] Introducing chromeos-kernel-next
>> Datum: 20.9.2010 05:28:17
>> ----------------------------------------
>> On Sat, Sep 18, 2010 at 9:13 AM, Rudolf Kutina (VirtGuru) <em...@post.cz>
>> wrote:
>> > Hi Olof,
>> >
>> > I have Aton N330+Ion and Atom D510 pineview systems, so I am interested if new
>> kernel can bring me:
>> >
>> >  - SSD disk trim support
>
> Looks like then Chromium OS (Chrome OS) count with SSD disk usage deeper then then I originally though,
> and TRIM (may be even newer disks with proactive Garbage Collectors) can be at the and  essential part of devices.
> Chrome OS design don't use swap and also looks then RAM is not massively used for caching (nor or OS-FS level,
> nor on Web Browesr level).  Looks current design simply count then SSD disk is fast enough without degradations.
>
> So it will be helpful to more considering and documeting used (needed) SSD  features like:
>  - format aligments (Allready imlementd, but not documented well in disk format doc)

Do you mean partition alignments?

>  - TRIM + Background Garbage Collection (preventing performance degradation over time )
>  - Transparent compression on latest SandForce chips (we use a lot of not compressible images)

compression is orthogonal since it's transparent to the OS.

>
> Experience: I upgrade from single core N230/1GB to dual core D510/1GB and later to dual core D510/2GB,
> no performance improvements perceived using USB disk with adding more 1GB RAM?

Sorry, I'm missing the point here. Seems obvious but adding RAM
doesn't always help. There are metrics available (e.g. IO rates, VM
activity) to determine if RAM is a bottleneck and how much RAM would
be needed to make a difference.

...

>> Last I heard, ext4 could issue TRIM commands but it wasn't quite ready
>> for prime yet.  I've not tested it myself so this is second hand info.
>
> TRIM support in ext4 is called "batched discard support" and looks its allready backported (merged) to ext3 ?

Thanks - I didn't remember the "batched discard support" name. Should
I care about ext3?

> http://www.listware.net/201007/linux-ext4/18682-ext4-batched-discard-support-simplified-version.html
>
> http://www.listware.net/201007/linux-ext4/19765-ext3-batched-discard-support.html
>
> http://www.listware.net/201007/linux-ext4/101684-patch-03-v3-batched-discard-support-for-ext3ext4.html
>
> Only I am afraid what happen if FS is mounted with "-o discard" paramemter on real or virtual non SSD disk.

In theory nothing should happen. It should only be a "performance
hint" to devices that can use it.

However, I don't see where the libata code checks to not send TRIM
commands to devices that don't support TRIM. I was looking at uses of
WRITE_SAME_16 (only supported by libata with unmap bit set),
ATA_DSM_TRIM, ata_id_has_trim() in drivers/ata, and
sd_prepare_discard() in drivers/scsi.

hth,
grant

[Rudolf Kutina (VirtGuru)]

> ------------ Původní zpráva ------------
> Od: Grant Grundler <grun...@chromium.org>
> Předmět: Re: [cros-dev] Introducing chromeos-kernel-next

> Datum: 20.9.2010 20:05:19
> ----------------------------------------

YES

>
> >  - TRIM + Background Garbage Collection (preventing performance degradation
> over time )
> >  - Transparent compression on latest SandForce chips (we use a lot of not
> compressible images)
>
> compression is orthogonal since it's transparent to the OS.

Yes, it's transparent as size, but not as performance, it looks like if content can't be compressible like JPEG image,
read/write performance drop to previous controller generation (and may be even bellow, because with SandForce + compression equipped with a cheaper slower chips will still fully saturate SATAII link at max values).
My opinion is then at leas from QA / Performance view it will need to be considered as separate TEST CASE.

> >
> > Experience: I upgrade from single core N230/1GB to dual core D510/1GB and
> later to dual core D510/2GB,
> > no performance improvements perceived using USB disk with adding more 1GB
> RAM?
>
> Sorry, I'm missing the point here. Seems obvious but adding RAM
> doesn't always help. There are metrics available (e.g. IO rates, VM
> activity) to determine if RAM is a bottleneck and how much RAM would
> be needed to make a difference.

I agree then this need more investigation, I found general discussions then
Chrome Browser at some point/version don't use a MEMORY cache as Firefox do ?
I just want to point then user will like to see all possible performance gains when adding more RAM>

>
> ...
> >> Last I heard, ext4 could issue TRIM commands but it wasn't quite ready
> >> for prime yet.  I've not tested it myself so this is second hand info.
> >
> > TRIM support in ext4 is called "batched discard support" and looks its
> allready backported (merged) to ext3 ?
>
> Thanks - I didn't remember the "batched discard support" name. Should
> I care about ext3?

Well it depend on ext4 maturity as Chromium OS will go over time.

>
> >
> http://www.listware.net/201007/linux-ext4/18682-ext4-batched-discard-support-simplified-version.html
> >
> >
> http://www.listware.net/201007/linux-ext4/19765-ext3-batched-discard-support.html
> >
> >
> http://www.listware.net/201007/linux-ext4/101684-patch-03-v3-batched-discard-support-for-ext3ext4.html
> >
> > Only I am afraid what happen if FS is mounted with "-o discard" paramemter on
> real or virtual non SSD disk.
>
> In theory nothing should happen. It should only be a "performance
> hint" to devices that can use it.
>
> However, I don't see where the libata code checks to not send TRIM
> commands to devices that don't support TRIM. I was looking at uses of
> WRITE_SAME_16 (only supported by libata with unmap bit set),
> ATA_DSM_TRIM, ata_id_has_trim() in drivers/ata, and
> sd_prepare_discard() in drivers/scsi.
>
> hth,
> grant
>
>
>

12 Minutes with Chromium OS http://wp.me/PLojB-id