gmane.linux.linaro.devel

Re: [LNG] RE: Deadline scheduler inclusion in linux-linaro?

Petri Savolainen — 2013-05-23T14:16:29

Hi,

Good progress that the adaptive tickless (CONFIG_NO_HZ_FULL) feature have
made it to the kernel 3.10. But there's still work to be done, since
(according to the LWN article) it is not fully tickless even when there's
only one thread on a core. If kernel is still running a 1 HZ tick, it saves
cycles but does not improve real-time properties of the system. The worst
case response time of a core is still limited to the longest kernel
maintenance task it may end up running during a tick (is there an upper
limit?). Also throughput will suffer from one or more cores running
maintenance and not processing packets. It adds jitter and makes it harder
to guarantee maximum throughput figures.

Data plane cores would need to pile up maintenance work and process it only
when told so ( application calling yield or some system calls).

About the multithread support, there would be only one truely tickless
thread per core. If there are others, time slicing is probably needed, at
least as a  backup (swap out data plane

Re: Hwpacks for OE builds?

Tom Gall — 2013-05-23T12:55:11

Chiming in.

We've been working to put together a linaro image with a graphics
stack that is based on xfce for OE.

I really like the idea that OE should output an axf and img that both
the Foundation and RTSM models can utilize straight away without a
hwpack or linaro-media-create. Extra steps are a drag.

Out of curiosity where is the code that outputs the root file system
for a tarball or ext3 img?

On Thu, May 23, 2013 at 5:34 AM, Fathi Boudra <fathi.boudra< at >linaro.org> wrote:

Test Result Summary of Calendar Week 21, 2013 for Linux Linaro ubuntu Raring.

Botao Sun — 2013-05-23T10:56:19

Calendar Week 21, 2013: Here is test result summary for Linux Linaro ubuntu
Raring image on following boards:

1) ARM Versatile Express A9;
2) Samsung Arndale;
3) TI Panda 4430;
4) TI Panda 4460;
5) ST Ericsson Snowball.

Synopsis: STE Snowball is not stable enough; "Reboot" works well on ARM
Versatile Express A9.

1. ARM Versatile Express A9 + Linux Linaro Raring (Column W):

https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdFNmV3gyZWRGVS12YUhqeW9rdkVZdmc#gid=1

Only "Halt" test failed, all other features work well.

2. Samsung Arndale + Linux Linaro Raring (Column Q):

https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AgB-fT5LL31CdGZJSFdTUWFFYVdhZl8wMFpxLXd2TXc#gid=0

"Halt" test failed; some errors show in power management test. All other
features work well.

3. TI Panda 4430 + Linux Linaro Raring (Column W):

https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZkhrZ1VYUEg2LTlQZzR0RlhzM3c#gid=3

WiFi and display output are unavailable; some errors show in

Re: Hwpacks for OE builds?

Fathi Boudra — 2013-05-23T10:34:50

Nico, I know your use case and I'm definitely not pushing on the
hwpack story specifically (even more for your project).

In other words, I don't think linaro specific approach is perfect and
I don't want to maintain the status quo (that's the goal of hwpackv4).
I want to move forward to improve the situation and be more efficient
but I'm not convinced the native approach is perfect either.
As I said previously, there's pros/cons for both solutions.

I'm glad there's interest on the topic and see you at Connect to have
a constructive discussion :)

Re: Hwpacks for OE builds?

Marcin Juszkiewicz — 2013-05-23T10:34:06

W dniu 23.05.2013 12:00, Riku Voipio pisze:


We can switch OE to generate same style images as linaro-media-create
does but it was never a priority.

Re: Hwpacks for OE builds?

Nicolas Dechesne — 2013-05-23T10:20:03



well, in my case, we might not have the choice, as you guessed it right,
there are other stakeholders, and i might not be able to justify an hwpack
solution as opposed to a native OE solution. i will get a better (complete)
picture by Connect, and we can discuss more then.
_______________________________________________
linaro-dev mailing list
linaro-dev-cunTk1MwBs8s++Sfvej+rw< at >public.gmane.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Hwpacks for OE builds?

Fathi Boudra — 2013-05-23T10:16:54

there's always "the only problem", and then you have another one and so on.
"greatly faster, simpler and more cost effective" that's what you said?
afaics, you're wasting your time (and probably some LAVA guys time) on
something already working...
what's the benefit?

Re: Hwpacks for OE builds?

Riku Voipio — 2013-05-23T10:00:49

It's not a big deal since LAVA started supporting prebuilt images. For
ARMv8 the only problem I had is that LAVA digs some files from the
rootfs partition, and due to hwpack/linaro-media-create LAVA expects
the rootfs to be the second partition, while the OE image doesn't have
a partition table.

Riku

Re: Hwpacks for OE builds?

Nicolas Dechesne — 2013-05-23T09:53:46


yes, guess so. and that's what's worries me a little bit too. and that's
why we need to talk about that at Connect!

cheers
nico
_______________________________________________
linaro-dev mailing list
linaro-dev-cunTk1MwBs8s++Sfvej+rw< at >public.gmane.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Hwpacks for OE builds?

Fathi Boudra — 2013-05-23T09:02:16

Your call (not only ;) I suspect your project has some stakeholders
requirements around OE native approach).
I'm guessing you'll have to make some adjustments if you want to
submit your pre-built images jobs to LAVA.

Re: Hwpacks for OE builds?

Nicolas Dechesne — 2013-05-23T08:43:26


well, as far as I am concerned and for my project i don't think that using
hwpack will make sense, and would prefer to go with an OE native approach,
even though we will support multiple BSP/SoC, that will be managed with
dedicated BSP layers. I will participate in the hwpacks v4 discussions at
connect though to align with you guys.
_______________________________________________
linaro-dev mailing list
linaro-dev-cunTk1MwBs8s++Sfvej+rw< at >public.gmane.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH] cpuidle: arm_big_little: pass target residency to mcpm

Sebastian Capella — 2013-05-22T18:51:12

Quoting Dave Martin (2013-05-22 11:22:36)

Thanks Dave, Liviu,

Sorry, you've caught me mixing terms and concepts.

I agree, target residency to me also is more an estimate of the cost vs.
benefit for a state.

The cstates also define a latency parameter that is used for limiting
selection of certain states by the governor.  This is affected by QoS 
constraints, which we use alot in embedded.  This is the one needed for
realtime use that is tricky with host os' additional latency.

Both latency and target residency would need some adjustment for
embedded mobile if we have additional overhead as it becomes very
important to squeeze this as much as possible.  For latency,
microseconds count as we cannot allow a cstate which will fail to meet
our qos constraints.

Thanks,

Sebastian

Re: [PATCH] cpuidle: arm_big_little: pass target residency to mcpm

Dave Martin — 2013-05-22T18:22:36

Currently not.  This partly depends on whether the target residency is
supposed to be a hint about the rough order of magnitude of the expected
idle period, or whether it's supposed to be a strict contract.

In effect, I think it's a hint which steers the choice of powerdown
state, rather than soemthing with a strong real-time guarantee attached
to it.  In that case shaving the firmware latency off this value before
using it may not be worth it.  If the specified target residency is
small enough that this makes a significant difference, this suggests a
very short period of actual powerdown, which may not outweigh its own
overheads in terms of power-saving.

That's just my view -- others may disagree

Cheers
---Dave

Re: [PATCH] cpuidle: arm_big_little: pass target residency to mcpm

Liviu Dudau — 2013-05-22T10:01:36

Quoting from the PSCI spec:

"ARM systems generally include a power controller which provides the necessary
mechanisms to control processor power. It normally provides interfaces to allow a number
of power management functions. These often include support for transitioning processors,
clusters or a superset, into low power states, where the processors are either fully switched
off, or in quiescent states where they are not executing code. ARM strongly recommends
that control of these states, via this power controller, is vested in the secure world.
Otherwise, the OSPM could enter a low power mode without informing the Trusted OS.
Even if such an arrangement could be made robust, it is unlikely to perform as well. In
particular, for states where the core is fully power gated, a longer boot sequence would
take place upon wake up as full initialization would be required by the secure world. This
would be required as the secure components would effectively be booting from scratch
every time. On a system where t

gator profiling

Chao Xie — 2013-05-22T01:48:06

hi
When i download the
git.linaro.org/git-ro/landing-teams/working/arm/kernel.git, there are
branches relates to gator.
I set up the enviroment at TC2 with gator and Dstream. I want to show
the CPU frequencies of big and little clusters, so i add code in gator
to get the frequency of the clusters. But it seems that gator  wakes
up in period and send out the message. So is there any way that make
gator to wake up based on events of cpu frequency changing, and send
out the message to Dstream?

Re: [PATCH] cpuidle: arm_big_little: pass target residency to mcpm

Sebastian Capella — 2013-05-21T21:08:29

Thanks Liviu!

Some comments below..

Quoting Liviu Dudau (2013-05-21 10:15:42)

Both, I'm really just trying to understand the problem.


I'm speaking more about additional c-states after the
lowest independent compute domain cstate, where we may add additional
cstates which reduce the power further at a higher latency cost.  These
may be changing power states for the rest of the SOC or external power
chips/supplies.  Those states would effectively enter the lowest PSCI
C-state, but then have additional steps in the CPUIdle hw specific
driver.


I was thinking maybe this also.. Is there a way to query the state
transition cost information through PSCI?  Would there be a way to
have the layers of hosts/monitors/etc contribute the cost of their
paths into the query results?


I agree, but don't see how.  In our systems, we do very much care about
the costs, and have ~real time constraints to manage.  I think
we need a good understanding of costs for the hw states.


I think that if we don't know the real cost

Re: [ANNOUNCE] linux-linaro kernel schedule for 13.05 published

Andrey Konovalov — 2013-05-21T18:48:30

Greetings,

On 05/20/2013 01:28 AM, Andrey Konovalov wrote:

May 20: ll rebuild based on llct-20130518.0
  * Done: the tag is ll-20130520.1
  * Changes:
    . Snowball build is fixed (the fix propagated from llct)
    . Snowball: ethernet works ok with the kernel config built from the 
config fragments (linaro-base + ubuntu-minimal + u8500)

May 21: v3.10-rc2 based linux-linaro-core-tracking (llct) rebuild
  * Done: the tag is llct-20130521.0
  * Changes:
    . interactive-gov-updates topic from Viresh Kumar added
    . arndale-core-support topic from Samsung LT added

No more llct updates are planned for 13.05 unless critical issues would 
be found in llct-20130521.0

The next steps are:
May 22: ll rebuild based on llct-20130521.0
May 23: ll rebuild based on llct-20130521.0, linux-linaro release 
candidate, code freeze


Thanks,
Andrey

Re: [GIT PULL]: ll-interactive-gov-updates : Per policy governor instance

Andrey Konovalov — 2013-05-21T18:43:10

Hi Viresh,

On 05/21/2013 10:20 AM, Viresh Kumar wrote:

Merged into v3.10-rc2 based llct-20130521.0.

Thanks,
Andrey

Re: [PATCH] cpuidle: arm_big_little: pass target residency to mcpm

Liviu Dudau — 2013-05-21T17:15:42

Hi Sebastian,


Not sure why the PSCI interface would have a say here. It's only
an interface between two pieces of code, it should not have state
awareness. Which side of the interface are you actually thinking of?


I don't think there is any C-state other than simple idle (which
translates into an WFI for the core) that *doesn't* take into account
power domain latencies and code path lengths to reach that state. I
don't see the usefulness of describing the latency of going into
CPU_OFF state without including all the steps to reach the state and
come back out of it.

Are you thinking of C-states that do not belong to the compute domain
but might still be part of the SoC? (things like an System MMU, or
a DMA engine, etc)


I don't know how to draw the line between the host OS costs and the
guest OS costs when using target latencies. On one hand I think that
the host OS should add its own costs into what gets passed to the
guest and the guest will see a slower than baremetal system in terms
of state transi

Re: Deadline scheduler inclusion in linux-linaro?

Juri Lelli — 2013-05-21T12:33:39

Hi,

On 05/17/2013 11:15 AM, Amit Kucheria wrote:

I just finished rebasing the patchset on top of 3.10-rc2. You can clone
the repo from git://github.com/jlelli/sched-deadline.git and checkout the
sched-dl-for-linaro branch, if you want to test it.

The test application I'm using is called rt-app and you can get it from
here: git://github.com/gbagnoli/rt-app.git

Any kind of feedback is welcome and appreciated.

Best,

- Juri

Re: Deadline scheduler inclusion in linux-linaro?

Juri Lelli — 2013-05-21T12:25:24

SCHED_DEADLINE does not depend on PREEMPT_RT. However, these two
patchsets can coexist, and you'll have benefits from both.



SCHED_DEADLINE does not address that kind of latency (time between
wakeup and actual execution). As Amit suggested, in the case you
can dedicate a core to a single task, you may want to disable timers
and perform no scheduling at all. In the end it's a matter of a ratio:
do you have enough cores to dedicate to single activities?

If the answer is no, than with SCHED_DEADLINE you can let critical
tasks run also on the same core and prove your system to be always
in a safe condition (if you account for scheduling overheads).

Best,

- Juri


_______________________________________________
linaro-dev mailing list
linaro-dev< at >lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev