On Thu, 23 Sep 2010, Catalin Marinas wrote:
> On Thu, 2010-09-23 at 16:15 +0100, Arnd Bergmann wrote:
> > On Thursday 23 September 2010, Nicolas Pitre wrote:
> > > > This highmem topic comes from the fact that highmem will be needed in
> > > > the period of time between now and LPAE where we hav
On Thursday 23 September 2010 19:03:42 Catalin Marinas wrote:
> On Thu, 2010-09-23 at 16:15 +0100, Arnd Bergmann wrote:
> > On Thursday 23 September 2010, Nicolas Pitre wrote:
> > > > This highmem topic comes from the fact that highmem will be needed in
> > > > the period of time between now and
On Thu, 2010-09-23 at 16:15 +0100, Arnd Bergmann wrote:
> On Thursday 23 September 2010, Nicolas Pitre wrote:
> > > This highmem topic comes from the fact that highmem will be needed in
> > > the period of time between now and LPAE where we have boards with lots
> > > of memory but we can't addr
On Thu, Sep 23, 2010, Arnd Bergmann wrote:
> The current state is mostly that people put unaligned partitions on their
> SD card, stick an ext3 fs on a partition and watch performance suck
> while destroying their cards.
Agreed :-)
> There has been a study by Thomas Gleixner on what CF cards do
On Thursday 23 September 2010, Nicolas Pitre wrote:
> > This highmem topic comes from the fact that highmem will be needed in
> > the period of time between now and LPAE where we have boards with lots
> > of memory but we can't address it all without highmem (unless we want
> > to revisit the 3
On Thursday 23 September 2010, Loïc Minier wrote:
> On Mon, Sep 20, 2010, Arnd Bergmann wrote:
> > Right. Having an intelligent file system is the only way I can see for
> > getting good speedups, by avoiding erase-cycles inside the SD card,
> > which commonly happen when you write to sectors at ra
On Thu, Sep 23, 2010, Nicolas Pitre wrote:
> The runtime patching of the kernel is useful for simple and
> straight-forward cases such as SMP ops which are performed in assembly.
> But in this case I'm afraid this could add even more overhead in the
> end, especially when highmem is active. But
On Thu, 23 Sep 2010, Loïc Minier wrote:
> On Mon, Sep 20, 2010, Arnd Bergmann wrote:
> > > Wrt highmem: I can't see the link with highmem and SMP. As far as I
> > > know, highmem on ARM should be SMP safe already (the only SMP related
> > > issue I've seen has been fixed in commit 831e8047eb).
On Thu, 23 Sep 2010, Loïc Minier wrote:
> When you say SDIO, you mean just SDIO or SD and SDIO?
I wrote a driver for one SD/SDIO host controller, played with the code
for two other controllers, and wrote part of the SDIO stack. All this
share common infrastructure with pure SD cards. Hence m
On Mon, Sep 20, 2010, Nicolas Pitre wrote:
> I'm also interested in both of those topics as 1) I participated in the
> design of the SDIO stack (closely related to SD), and 2) I did the
> highmem implementation for ARM.
(You're awesome! :-)
When you say SDIO, you mean just SDIO or SD and SDI
On Mon, Sep 20, 2010, Arnd Bergmann wrote:
> > Wrt highmem: I can't see the link with highmem and SMP. As far as I
> > know, highmem on ARM should be SMP safe already (the only SMP related
> > issue I've seen has been fixed in commit 831e8047eb).
>
> Right, it's not related to SMP, I was thinki
On Mon, Sep 20, 2010, Arnd Bergmann wrote:
> Right. Having an intelligent file system is the only way I can see for
> getting good speedups, by avoiding erase-cycles inside the SD card,
> which commonly happen when you write to sectors at random addresses.
>
> There has been a lot of research in o
On Tue, Sep 21, 2010 at 12:57:47PM -0700, Paul E. McKenney wrote:
> > There's was relationship between runtime UP detection and highmem
> > discussed in the meeting; the bigger point here is that we want to
> > ensure the kernel is stellar at supporting our architectural baseline:
> > platforms tha
On Tue, Sep 21, 2010 at 12:57:35PM -0300, Christian Robottom Reis wrote:
> On Mon, Sep 20, 2010 at 10:35:52AM -0700, Paul E. McKenney wrote:
> > > I still have two questions about stuff that came up here:
> > >
> > > * SD/MMC performance: Is this about device access, file systems or both?
> > >
On Tue, Sep 21, 2010, Robert Schwebel wrote:
> It would be great to see more MX51 things on ALKML (and devicetree
> things on devtree-discuss). Up to now I have the impression that there
> is still much work done behind closed doors, which is bad if we want to
> have better mainline support for i.M
On 09/21/2010 11:02 AM, Christian Robottom Reis wrote:
> On Tue, Sep 21, 2010 at 12:15:17AM +0200, Robert Schwebel wrote:
>> On Mon, Sep 20, 2010 at 09:19:49AM -0700, Paul E. McKenney wrote:
>>> o Jason Hui: iMX51 work on device trees. Need assignment.
>>> Reviewed BSP review
On Tue, Sep 21, 2010 at 12:15:17AM +0200, Robert Schwebel wrote:
> On Mon, Sep 20, 2010 at 09:19:49AM -0700, Paul E. McKenney wrote:
> > o Jason Hui: iMX51 work on device trees. Need assignment.
> > Reviewed BSP review, need to send results to Loïc et al.
>
> It would be gre
On Mon, Sep 20, 2010 at 10:35:52AM -0700, Paul E. McKenney wrote:
> > I still have two questions about stuff that came up here:
> >
> > * SD/MMC performance: Is this about device access, file systems or both?
> > I think the file system level stuff is actually the more important
> > part but I
On Mon, Sep 20, 2010 at 09:19:49AM -0700, Paul E. McKenney wrote:
> o Jason Hui: iMX51 work on device trees. Need assignment.
> Reviewed BSP review, need to send results to Loïc et al.
It would be great to see more MX51 things on ALKML (and devicetree
things on devtree-d
On Monday 20 September 2010 19:50:59 Nicolas Pitre wrote:
> >
> > I believe that this is related to LPAE -- the usual 32-bit-only DMA
> > devices in a >32-bit physical address space. But there was also
> > discussion about run-time patching for SMP alternatives, though I am
> > missing how this r
On Mon, 20 Sep 2010, Paul E. McKenney wrote:
> On Mon, Sep 20, 2010 at 06:37:05PM +0200, Arnd Bergmann wrote:
> > On Monday 20 September 2010, Paul E. McKenney wrote:
> > > o Kernel requirements
> > > (https://wiki.linaro.org/Internal/TSC/MinutesToBeAgreed)
> > >
> >
> > I still ha
On Mon, Sep 20, 2010 at 06:10:16PM +0100, Jamie Bennett wrote:
> On 20 Sep 2010, at 17:19, Paul E. McKenney wrote:
> > o Requirements schedule
> >
> > o Requirements discussion, mostly in TSC.
> > o Discussion and refinement at Orlando.
> > o Blueprint generation in
On Mon, Sep 20, 2010 at 06:37:05PM +0200, Arnd Bergmann wrote:
> On Monday 20 September 2010, Paul E. McKenney wrote:
> > o Kernel requirements
> > (https://wiki.linaro.org/Internal/TSC/MinutesToBeAgreed)
> >
>
> I still have two questions about stuff that came up here:
>
> * SD/MM
On 20 Sep 2010, at 17:19, Paul E. McKenney wrote:
> o Requirements schedule
>
> o Requirements discussion, mostly in TSC.
> o Discussion and refinement at Orlando.
> o Blueprint generation in the 2-3 weeks following Orlando.
I'd just like to point out that
On Monday 20 September 2010, Paul E. McKenney wrote:
> o Kernel requirements
> (https://wiki.linaro.org/Internal/TSC/MinutesToBeAgreed)
>
I still have two questions about stuff that came up here:
* SD/MMC performance: Is this about device access, file systems or both?
I think the
Hello!
Please see below for my rough notes from the kernel consolidation,
and please reply to the group with any errors or omissions.
Thanx, Paul
Attendees: Arnd Berg
26 matches
Mail list logo
