Thoughts?
Thanx, Paul
----- Forwarded message from Jesper Juhl <jj(a)chaosbits.net> -----
Date: Sun, 6 Mar 2011 00:49:58 +0100 (CET)
From: Jesper Juhl <jj(a)chaosbits.net>
To: linux-kernel(a)vger.kernel.org
cc: Andrew Morton <akpm(a)linux-foundation.org>,
"Paul E. McKenney" <paulmck(a)linux.vnet.ibm.com>,
Ingo Molnar <mingo(a)elte.hu>,
Daniel Lezcano <daniel.lezcano(a)free.fr>,
Eric Paris <eparis(a)redhat.com>,
Roman Zippel <zippel(a)linux-m68k.org>
Subject: [PATCH][RFC] CC_OPTIMIZE_FOR_SIZE should default to N
I believe that the majority of systems we are built on want a -O2 compiled
kernel. Optimizing for size (-Os) is mainly benneficial for embedded
systems and systems with very small CPU caches (correct me if I'm wrong).
So it seems wrong to me that CC_OPTIMIZE_FOR_SIZE defaults to 'y' and
recommends saying 'Y' if unsure. I believe it should default to 'n' and
recommend that if unsure. People who bennefit from -Os know who they are
and can enable the option if needed/wanted - the majority shouldn't
select this. Right?
Signed-off-by: Jesper Juhl <jj(a)chaosbits.net>
---
Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index be788c0..7e16268 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -886,12 +886,12 @@ endif
config CC_OPTIMIZE_FOR_SIZE
bool "Optimize for size"
- default y
+ default n
help
Enabling this option will pass "-Os" instead of "-O2" to gcc
resulting in a smaller kernel.
- If unsure, say Y.
+ If unsure, say N.
config SYSCTL
bool
--
Jesper Juhl <jj(a)chaosbits.net> http://www.chaosbits.net/
Plain text mails only, please.
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
----- End forwarded message -----
tl;dr version: see https://android-build.linaro.org/mockup/index, click
around. Don't expect to be able to do much unless you're in
~linaro-android-builders
Hi all,
The frontend to the build service that I've been working on for the last
couple of weeks is -- to my understanding <wink> -- now feature
complete. You can see it at:
https://android-build.linaro.org/mockup/index
It works better in chrome than firefox currently, although I hope to be
through the worst of that soon.
You can log in using your Launchpad ID, but access to the interesting
functionality (being able to trigger, edit and set up builds) is
restricted to members of the ~linaro-android-builders team (I've made
Loic, Alexander and Patryk admins of this team as well as myself).
There is another team, ~linaro-android-official-builders, whose members
can make "official" builds.
I've tried pretty hard to make things self explanatory so I don't want
to explain too much here. One thing that probably needs explaining is
that a "configuration" is a snippet of shell that sets various
environment variables that are interpreted by the build scripts, such as
MANIFEST_REPO, MANIFEST_BRANCH and the various TARGET_* variables
understood by the android build tools.
If there's something missing from this or some aspect that seems really
badly designed, *please* tell me! Otherwise I'll assume you all love
it. I hear a rumour that Alexander wants simpler browsing of build
artefacts. I also know it's not especially pretty and the error
handling & reporting is a bit inconsistent.
If you're curious as to how it works, the web interface is a frontend to
jenkins, which is serving at https://android-build.linaro.org/jenkins.
Each configuration corresponds to a job in jenkins, with the
configuration data stored as the default value for a parameter. There's
a lot of javascript (using YUI 3) going on, and in particular most pages
get the data they display by making ajax requests directly to jenkins'
remote access API. The rest of it is a Django web application, which
handles generating the html (though this are only very very lightly
templated) and handling the 'write' operations that need server side
access control.
The code is in lp:~mwhudson/linaro-android/frontend on Launchpad and is
pretty messy, although still fairly small (around 1500 lines of code).
I plan to spend some time over the next week making the code much more
maintainable, but I don't have any other plans for this code myself.
Now get criticizing!
Cheers,
mwh
Hello everyone,
The following patchset implements a "hardware memory driver". The
main purpose of hwmem is:
* To allocate buffers suitable for use with hardware. Currently
this means contiguous buffers.
* To synchronize the caches for the allocated buffers. This is
achieved by keeping track of when the CPU uses a buffer and when
other hardware uses the buffer, when we switch from CPU to other
hardware or vice versa the caches are synchronized.
* To handle sharing of allocated buffers between processes i.e.
import, export.
Hwmem is available both through a user space API and through a
kernel API.
Here at ST-Ericsson we use hwmem for graphics buffers. Graphics
buffers need to be contiguous due to our hardware, are passed
between processes (usually application and window manager)and are
part of usecases where performance is top priority so we can't
afford to synchronize the caches unecessarily.
Additions in v2:
* Bugfixes
* Added the possibility to map hwmem buffers in the kernel through
hwmem_kmap/kunmap
* Moved mach specific stuff to mach.
Best regards
Johan Mossberg
Consultant at ST-Ericsson
Johan Mossberg (3):
hwmem: Add hwmem (part 1)
hwmem: Add hwmem (part 2)
hwmem: Add hwmem to ux500
arch/arm/mach-ux500/Makefile | 2 +-
arch/arm/mach-ux500/board-mop500.c | 1 +
arch/arm/mach-ux500/dcache.c | 266 +++++++++
arch/arm/mach-ux500/devices.c | 31 ++
arch/arm/mach-ux500/include/mach/dcache.h | 26 +
arch/arm/mach-ux500/include/mach/devices.h | 1 +
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/hwmem/Kconfig | 7 +
drivers/misc/hwmem/Makefile | 3 +
drivers/misc/hwmem/cache_handler.c | 510 ++++++++++++++++++
drivers/misc/hwmem/cache_handler.h | 61 +++
drivers/misc/hwmem/hwmem-ioctl.c | 455 ++++++++++++++++
drivers/misc/hwmem/hwmem-main.c | 799 ++++++++++++++++++++++++++++
include/linux/hwmem.h | 536 +++++++++++++++++++
15 files changed, 2699 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-ux500/dcache.c
create mode 100644 arch/arm/mach-ux500/include/mach/dcache.h
create mode 100644 drivers/misc/hwmem/Kconfig
create mode 100644 drivers/misc/hwmem/Makefile
create mode 100644 drivers/misc/hwmem/cache_handler.c
create mode 100644 drivers/misc/hwmem/cache_handler.h
create mode 100644 drivers/misc/hwmem/hwmem-ioctl.c
create mode 100644 drivers/misc/hwmem/hwmem-main.c
create mode 100644 include/linux/hwmem.h
--
1.7.4.1
I'm recently trying to install alpha-3 image using l-m-c on an AMD64
machine which is behind the company firewall. Though I have apt proxy
set on host machine, l-m-c installing system (chroot env?) does not
know it. Can we improve the l-m-c a little bit to copy apt proxy
setting if any on host machine into installing system? So that the
machine behind proxy can survive with l-m-c too.
PS.
Actually, I have my machine home which can directly access natty
repository, but it's very slow (see below), probably because there
is no natty mirror in China yet.
Fetched 15.0 MB in 10min 22s (24.1 kB/s)
When I use vpn to connect company network, speed of accessing ubuntu
repository can reach ~200 kB/s. Considering that I'm testing l-m-c
back and forth, I really need a faster apt speed within l-m-c.
--
Regards,
Shawn
Enclosed you'll find a link to the agenda, notes and actions from the
Linaro Developer Platforms Weekly Status meeting held on March 9th
in #linaro-meeting on irc.freenode.net at 16:00 UTC.
https://wiki.linaro.org/Platform/Foundations/2011-03-09
Actions from the meeting where as follows:
* wookey_ to send a patch to debian-policy to allow multiarch -dev packages
* jcrigby and hrw to figure out how to boot efikasb from an external
u-boot so hrw can test the latest tree
* jcrigby to check with dmart about progress on porting kprobes to thumb-2
* ppearse to investigate how libtool does ldopen for GObject
Introspection work
Regards,
Tom (tgall_foo)
Developer Platforms Team
"We want great men who, when fortune frowns will not be discouraged."
- Colonel Henry Knox
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com
Hi,
The Infrastructure team weekly report for 2011-03-10 is now available
and can be found at:
https://wiki.linaro.org/Platform/Infrastructure/Status/2011-03-10
The report is also reproduced in full below.
Regards,
Jamie.
--
Linaro Release Manager | Platform Project Manager
--
* Period: (20110303-20110309)
* PM: JamieBennett <jamie.bennett(a)linaro.org>
* Past reports : https://wiki.linaro.org/Platform/Infrastructure/Status
* Burndown information :
http://status.linaro.org/linaro-infrastructure.html
* Stakeholder process:
https://wiki.linaro.org/Platform/Infrastructure/CurrentProjects
== Key Points for wider discussion ==
* A 'feature-complete' version of the Android build system front-end to
Jenkins is available at {{{https://android-build.linaro.org/mockup/}}}.
Builds can be done by members of the ~linaro-android-builders Launchpad
team and the actual Jenkins instance can be found at
{{{http://android-build.linaro.org/jenkins}}}. Please take a look and
give comments.
* svammel mass bug filing tool for build failures is progressing. Some
more improvements planned but initial reviews are favorable. Code
reviews are welcome.
== Team Highlights ==
* ec2 investigations continue to find the best solution for the
continuous integration service. An ebs instance either small or large
for the master and include slaves as when needed for builds seems the
most effective.
* Mattias and Deepti now have Panda boards although Deepti's is shared
at the moment.
* Initial patch tracking metrics have been given to management.
* Tracking bugs as work items on non-Ubuntu projects was enabled in the
status.linaro.org code.
* Initial work on a planet instance for Linaro has been undertaken. The
results can be found at
[[http://ec2-50-17-53-200.compute-1.amazonaws.com/]]
== Upcoming Deliverables ==
* linaro-image-tools will be getting a release soon (likely before the
monthly release date to ease the process of getting it in to Ubuntu)
* Final patch metrics for the next member report in two weeks.
== Risks / Issues ==
* '''VERY HIGH IMPACT''': Mattias unable to work productively due to IT
restrictions in ST-E (5 weeks): some progress. Has process now to
request changes, but little response to his requests in more than 4
weeks. Mattias is working from home or over 3G in the meantime.
* '''HIGH IMPACT''': PatchTracking requires deploying Patchwork (4
weeks): Discussion with IS, and it is not expected to take them long to
do once they get to it. They have indicated that they may be able to
start at the end of this week, or in the week after.
* '''HIGH IMPACT''': Gerrit instance needed for Android (4 weeks):
Co-ordination with IS has started. Waiting to hear from them if we can
get it this month, and what we need to do to help with that.
* '''HIGH IMPACT''': Deepti believes she has not been granted travel to
Linaro@UDS (2 weeks): She will attend remotely where possible.
* '''HIGH IMPACT''': A large portion of James' time is taken by project
management at the moment (several weeks): investigations are in progress
on how to move most of this work onto a PM.
* '''MEDIUM IMPACT''': Deepti lacking hardware to work with her Panda
board: Deepti has received the Panda board, but doesn't have a
USB->serial cable for it, so is still unable to use it for much. Working
on tasks that don't require it, but unable to participate in image
testing. (many weeks).
* '''MEDIUM IMPACT''': OurOwnOffspring lacking hardware (many weeks):
x86 for master is ready and waiting, XMs for slaves delivered to IS.
Awaiting setup from IS.
* '''MEDIUM IMPACT''': Want a Jenkins/Hudson instance for Continuous
Integration purposes (many weeks): Discussions with IS, and they will
provide one, but timeframe is unclear at this point. Will host ourselves
until IS can provide. Work on getting an ec2 instance for this has
started, and we should have it running in ec2 by next week.
* '''MEDIUM IMPACT''': Deepti and Avik are sharing one Panda board
meaning some hardware specific work is being blocked (1 week).
== Miscellaneous ==
* Guilherme at PyCon 10-15 March
* James away 21st March
* Deepti on vacation 11th March
Hi,
The Android team weekly report for 2011-03-10 is now available and can
be found at:
https://wiki.linaro.org/Platform/Android/Status/2011-03-10
The report is also reproduced in full below.
Regards,
Jamie.
--
Linaro Release Manager | Platform Project Manager
--
* Period: (20110303-20110309)
* PM: JamieBennett <jamie.bennett(a)linaro.org>
* Past reports : https://wiki.linaro.org/Platform/Android/Status
== Key Points for wider discussion ==
* Framebuffer patches still need more discussion
* Team is discovering and discussing Blueprints to work on this and
next cycle. More input from other teams is encouraged.
== Team Highlights ==
* Improvements to linaro-media-create (not merged yet) and basic
validation of the Android images.
* Working on delivering the first binary Linaro toolchain for Android.
This will then be validated using existing validation tools and a
report sent next week.
* More work defining the Android LEB to clearly understand what needs
to be delivered in our images.
* Framebuffer and Power Management work continues with the former due
to land next week.
* Two Panda boards are destined for the team although there is a
problem with one on them (see below).
== Upcoming Deliverables ==
* None.
== Risks / Issues ==
* '''HIGH IMPACT''': Kenjie Watanabe states that his company committed
him to work in Linaro but he currently has no time for this. Noritsuna
will discuss the problem with the president of his company next week (3
weeks). We have now been informed that they will get clearance to work
on the Project in April.
* '''HIGH IMPACT''': Currently the Linaro Android efforts are based on
2.6.37 but with Linaro moving to 2.6.38 and the upstream Android 2.6.38
kernel being available some rebasing efforts will be needed. John
Stultz, Patrik Ryd and others need to discuss how this can be done in
the smoothest way (3 weeks). Some amount of effort will be needed but
that effort is unclear at this point. Will lower level after initial
investigations if necessary. Tree still needs to be produced for any
assessment can be made.
* '''MEDIUM IMPACT''': Contribution agreements with Google for AOSP
development still waiting to be approved for Alexander Sack and Patrik
Ryd (1 week).
* '''MEDIUM IMPACT''': Patriks Panda board is lost in the postal
system atm. Sent by Mounir from IBM, Patrik is chasing tracking numbers
(1 week).
* '''MEDIUM IMPACT''': Patrik lost some time last week due to an
internal project at ST-E. Need to monitor to ensure Patrik stays focused
on Linaro.
* '''LOW IMPACT''': jstultz lost some days last week due to sickness.
He is focussing on kconfig work for Linaro atm.
== Miscellaneous ==
* Wiki pages of note this week:
* https://wiki.linaro.org/Platform/Android/CurrentProjects
Hi,
You can get all the information at
https://wiki.linaro.org/Platform/Infrastructure/Meetings/2011-03-08
Thanks,
James
== Agenda ==
* Actions from last meeting
* Team Status
* AOB
== Past Action items ==
* james_w to co-ordinate deployment of salgado's patchwork tree in his absence
* james_w to email salgado about patch metrics
* james_w to get deepti a machine to host jenkins
* mabac to request reviews for some svammel changes, and review some code from other team members
* salgado to send deployment docs to the patchwork RT ticket when ready
* james_w to request status reports on Monday
== Action Items ==
* james_w to co-ordinate deployment of salgado's patchwork tree in his absence
* mabac to request reviews for some svammel changes, and review some code from other team members
* salgado to send deployment docs to the patchwork RT ticket when ready
* james_w to reassign CI spec and ask for workitems
* mwhudson to add some people to https://launchpad.net/~linaro-android-builders
* mwhudson to talk to plars about lava
