[uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Bair, Richard]

I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale BSP) and 
am working to make it run on the 2.6.38 kernel released in the ColdFire BSP in 
Feb 2012.  I'm concerned about memory allocation as my first attempt to run on 
the 38 kernel appears to be using 2^n memory allocation vs. allocation that 
sizes just 1-page over the application.

1) Can anyone tell me the exact kernel config name that needs to be adjusted 
for the 38 kernel to set the default memory allocation?
- Older posts indicate modules like page_alloc2 or Kmalloc2 control 
this so I'm going to investigate these in more detail
- RTFMing indicate that this might be the area but I don't see it in 
the 38 version (LTIB or make menucionfig):
menuconfig -> kernel settings -> general settings, try enabling 
either the "Permit large allocations" setting, or the "non-power-of-2"

2) Historically, we use LTIB to create the kernel.  Does LTIB expose most/all 
settings of the 2.6.38 kernel?  Can it be out of sync with the make menuconfig 
uClinus kernel?

Thanks!

___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

[uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Bair, Richard]

Still struggling with 2.6.38 kernel and memory allocation.  We've been RTFMing 
but still aren't able to run on 2.6.38.  Any insight much appreciated.

BACKGROUND:
===
- Application is unchanged and runs on 2.6.26 and not on 2.6.38.  Both versions 
are based on Freescale BSP releases.
- Application only has 32MB of RAM total...same for both working and failing 
case.
- Application will "spawn" 3x additional threads.
- Application is 4.7MB application...it appears to allocate 8Mb then an 
additional 8MB for each thread.  I believe this occurs via vfork().

THOUGHTS:
=
- It is my understanding that 2^n allocation has been present since 2.6 
introduction so I think this is the same from version 26 to 38.

Q1:  Does the kernel always allocate memory via mmap()? 
Q2:  Is mmap() used for kernel allocation and user-land allocation?
Q3:  Is there a good summary of exactly what transpires in terms of 
memory allocation as the kernel runs a user-land program?

- If mmap() is the primary allocator, I think there may be a "trimming 
capability" difference from 26 to 38 based on Len Sorensen's input for memory 
allocations by mmap() as follows: 

 (1) Keep the excess as dead space.  The dead space then remains unused for 
the
 lifetime of the mapping.  Mappings of shared objects such as libc, 
ld.so
 or busybox's text segment may retain their dead space forever.

 (2) Return the excess to the allocator.  This means that the dead space is
 limited to less than a page per mapping, but it means that for a 
transient
 process, there's more chance of fragmentation as the excess space may 
be
 reused fairly quickly.

Q4:  Has anyone used option 2 and if so exactly how do you set the 
variable and when?  For the when part, do you do this post the kernel bring up?
Q5:  It sounds like a common method is to not "trim" during boot and 
then turn this on for large memory allocations...true?  Recommended?
Q6:  Can anyone confirm if 26 was configured to always trim memory 
after allocation and 38 is not?

- Tools for better memory utilization debug:

Q7:  What tools can we use to better understand the memory footprint of 
the application and threads?  We're using Top but need significantly more   
detail.
Q8:  Is there a proc location that details memory allocation per 
program?

In summary, any recommendations on how to debug memory allocation would be most 
helpful.  At this time our Freescale support has been unhelpful in resolving 
this issue.

Thanks!
-Rich
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Lennart Sorensen]

On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote:
> I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale BSP) and 
> am working to make it run on the 2.6.38 kernel released in the ColdFire BSP 
> in Feb 2012.  I'm concerned about memory allocation as my first attempt to 
> run on the 38 kernel appears to be using 2^n memory allocation vs. allocation 
> that sizes just 1-page over the application.
> 
> 1) Can anyone tell me the exact kernel config name that needs to be adjusted 
> for the 38 kernel to set the default memory allocation?
>   - Older posts indicate modules like page_alloc2 or Kmalloc2 control 
> this so I'm going to investigate these in more detail
>   - RTFMing indicate that this might be the area but I don't see it in 
> the 38 version (LTIB or make menucionfig):
>   menuconfig -> kernel settings -> general settings, try enabling 
> either the "Permit large allocations" setting, or the "non-power-of-2"
> 
> 2) Historically, we use LTIB to create the kernel.  Does LTIB expose most/all 
> settings of the 2.6.38 kernel?  Can it be out of sync with the make 
> menuconfig uClinus kernel?

Maybe this changed the behaviour you see:

commit fc4d5c292b68ef02514d2072dcbf82d090c34875
Author: David Howells 
Date:   Wed May 6 16:03:05 2009 -0700

nommu: make the initial mmap allocation excess behaviour Kconfig 
configurable

NOMMU mmap() has an option controlled by a sysctl variable that determines
whether the allocations made by do_mmap_private() should have the excess
space trimmed off and returned to the allocator.  Make the initial setting
of this variable a Kconfig configuration option.

The reason there can be excess space is that the allocator only allocates
in power-of-2 size chunks, but mmap()'s can be made in sizes that aren't a
power of 2.

There are two alternatives:

 (1) Keep the excess as dead space.  The dead space then remains unused for 
the
 lifetime of the mapping.  Mappings of shared objects such as libc, 
ld.so
 or busybox's text segment may retain their dead space forever.

 (2) Return the excess to the allocator.  This means that the dead space is
 limited to less than a page per mapping, but it means that for a 
transient
 process, there's more chance of fragmentation as the excess space may 
be
 reused fairly quickly.

During the boot process, a lot of transient processes are created, and
this can cause a lot of fragmentation as the pagecache and various slabs
grow greatly during this time.

By turning off the trimming of excess space during boot and disabling
batching of frees, Coldfire can manage to boot.

A better way of doing things might be to have /sbin/init turn this option
off.  By that point libc, ld.so and init - which are all long-duration
processes - have all been loaded and trimmed.

Reported-by: Lanttor Guo 
Signed-off-by: David Howells 
Tested-by: Lanttor Guo 
Cc: Greg Ungerer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 

After all before this commit, trimming after allocating was always done.
Now it is only done if you enable this CONFIG, or set the sysctl flag
at runtime, which of course affects behaviour for all allocations after
you change the setting.

-- 
Len Sorensen
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Raju B]

whenever i am trying to receive data from serial communication continuously
in uClinux, I am getting every 10th byte is overwrite by 11 byte and so
on

 Iam using freescale coldfire processor. Could you any body  please help me
to resolve this issue.

Thanks & Regards,
Raj


On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:

> On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote:
> > I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale
> BSP) and am working to make it run on the 2.6.38 kernel released in the
> ColdFire BSP in Feb 2012.  I'm concerned about memory allocation as my
> first attempt to run on the 38 kernel appears to be using 2^n memory
> allocation vs. allocation that sizes just 1-page over the application.
> >
> > 1) Can anyone tell me the exact kernel config name that needs to be
> adjusted for the 38 kernel to set the default memory allocation?
> >   - Older posts indicate modules like page_alloc2 or Kmalloc2
> control this so I'm going to investigate these in more detail
> >   - RTFMing indicate that this might be the area but I don't see it
> in the 38 version (LTIB or make menucionfig):
> >   menuconfig -> kernel settings -> general settings, try
> enabling either the "Permit large allocations" setting, or the
> "non-power-of-2"
> >
> > 2) Historically, we use LTIB to create the kernel.  Does LTIB expose
> most/all settings of the 2.6.38 kernel?  Can it be out of sync with the
> make menuconfig uClinus kernel?
>
> Maybe this changed the behaviour you see:
>
> commit fc4d5c292b68ef02514d2072dcbf82d090c34875
> Author: David Howells 
> Date:   Wed May 6 16:03:05 2009 -0700
>
> nommu: make the initial mmap allocation excess behaviour Kconfig
> configurable
>
> NOMMU mmap() has an option controlled by a sysctl variable that
> determines
> whether the allocations made by do_mmap_private() should have the
> excess
> space trimmed off and returned to the allocator.  Make the initial
> setting
> of this variable a Kconfig configuration option.
>
> The reason there can be excess space is that the allocator only
> allocates
> in power-of-2 size chunks, but mmap()'s can be made in sizes that
> aren't a
> power of 2.
>
> There are two alternatives:
>
>  (1) Keep the excess as dead space.  The dead space then remains
> unused for the
>  lifetime of the mapping.  Mappings of shared objects such as
> libc, ld.so
>  or busybox's text segment may retain their dead space forever.
>
>  (2) Return the excess to the allocator.  This means that the dead
> space is
>  limited to less than a page per mapping, but it means that for a
> transient
>  process, there's more chance of fragmentation as the excess space
> may be
>  reused fairly quickly.
>
> During the boot process, a lot of transient processes are created, and
> this can cause a lot of fragmentation as the pagecache and various
> slabs
> grow greatly during this time.
>
> By turning off the trimming of excess space during boot and disabling
> batching of frees, Coldfire can manage to boot.
>
> A better way of doing things might be to have /sbin/init turn this
> option
> off.  By that point libc, ld.so and init - which are all long-duration
> processes - have all been loaded and trimmed.
>
> Reported-by: Lanttor Guo 
> Signed-off-by: David Howells 
> Tested-by: Lanttor Guo 
> Cc: Greg Ungerer 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
>
> After all before this commit, trimming after allocating was always done.
> Now it is only done if you enable this CONFIG, or set the sysctl flag
> at runtime, which of course affects behaviour for all allocations after
> you change the setting.
>
> --
> Len Sorensen
> ___
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev
>
___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Michael Durrant]

Raj,

Which ColdFire are you using?
Which serial interface are you seeing this with (UART/SPI/I2C/..)?

Michael


On 11/05/2013 07:40 AM, Raju B wrote:

whenever i am trying to receive data from serial communication continuously in 
uClinux, I am getting every 10th byte is overwrite by 11 byte and so on

 Iam using freescale coldfire processor. Could you any body please help me to 
resolve this issue.

Thanks & Regards,
Raj


On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen mailto:lsore...@csclub.uwaterloo.ca>> wrote:

On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote:
> I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale BSP) 
and am working to make it run on the 2.6.38 kernel released in the ColdFire BSP in 
Feb 2012.  I'm concerned about memory allocation as my first attempt to run on the 
38 kernel appears to be using 2^n memory allocation vs. allocation that sizes just 
1-page over the application.
>
> 1) Can anyone tell me the exact kernel config name that needs to be 
adjusted for the 38 kernel to set the default memory allocation?
>   - Older posts indicate modules like page_alloc2 or Kmalloc2 control 
this so I'm going to investigate these in more detail
>   - RTFMing indicate that this might be the area but I don't see it 
in the 38 version (LTIB or make menucionfig):
>   menuconfig -> kernel settings -> general settings, try enabling either the 
"Permit large allocations" setting, or the "non-power-of-2"
>
> 2) Historically, we use LTIB to create the kernel.  Does LTIB expose 
most/all settings of the 2.6.38 kernel?  Can it be out of sync with the make 
menuconfig uClinus kernel?

Maybe this changed the behaviour you see:

commit fc4d5c292b68ef02514d2072dcbf82d090c34875
Author: David Howells mailto:dhowe...@redhat.com>>
Date:   Wed May 6 16:03:05 2009 -0700

nommu: make the initial mmap allocation excess behaviour Kconfig 
configurable

NOMMU mmap() has an option controlled by a sysctl variable that 
determines
whether the allocations made by do_mmap_private() should have the excess
space trimmed off and returned to the allocator.  Make the initial 
setting
of this variable a Kconfig configuration option.

The reason there can be excess space is that the allocator only 
allocates
in power-of-2 size chunks, but mmap()'s can be made in sizes that 
aren't a
power of 2.

There are two alternatives:

 (1) Keep the excess as dead space.  The dead space then remains unused 
for the
 lifetime of the mapping.  Mappings of shared objects such as libc, 
ld.so
 or busybox's text segment may retain their dead space forever.

 (2) Return the excess to the allocator.  This means that the dead 
space is
 limited to less than a page per mapping, but it means that for a 
transient
 process, there's more chance of fragmentation as the excess space 
may be
 reused fairly quickly.

During the boot process, a lot of transient processes are created, and
this can cause a lot of fragmentation as the pagecache and various slabs
grow greatly during this time.

By turning off the trimming of excess space during boot and disabling
batching of frees, Coldfire can manage to boot.

A better way of doing things might be to have /sbin/init turn this 
option
off.  By that point libc, ld.so and init - which are all long-duration
processes - have all been loaded and trimmed.

Reported-by: Lanttor Guo mailto:lanttor@freescale.com>>
Signed-off-by: David Howells mailto:dhowe...@redhat.com>>
Tested-by: Lanttor Guo mailto:lanttor@freescale.com>>
Cc: Greg Ungerer mailto:g...@snapgear.com>>
Signed-off-by: Andrew Morton mailto:a...@linux-foundation.org>>
Signed-off-by: Linus Torvalds mailto:torva...@linux-foundation.org>>

After all before this commit, trimming after allocating was always done.
Now it is only done if you enable this CONFIG, or set the sysctl flag
at runtime, which of course affects behaviour for all allocations after
you change the setting.

--
Len Sorensen
___
uClinux-dev mailing list
uClinux-dev@uclinux.org 
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org 

To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev




___
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev


__

Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Raju B]

Hi Michael,

The ColdFire is 523x and using UART serial interface.

Thanks & regards,
Raju B


On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant wrote:

>
> Raj,
>
> Which ColdFire are you using?
> Which serial interface are you seeing this with (UART/SPI/I2C/..)?
>
> Michael
>
>
> On 11/05/2013 07:40 AM, Raju B wrote:
>
>   whenever i am trying to receive data from serial communication
> continuously in uClinux, I am getting every 10th byte is overwrite by 11
> byte and so on
>
>   Iam using freescale coldfire processor. Could you any body  please help
> me to resolve this issue.
>
>  Thanks & Regards,
>  Raj
>
>
> On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen <
> lsore...@csclub.uwaterloo.ca> wrote:
>
>> On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote:
>> > I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale
>> BSP) and am working to make it run on the 2.6.38 kernel released in the
>> ColdFire BSP in Feb 2012.  I'm concerned about memory allocation as my
>> first attempt to run on the 38 kernel appears to be using 2^n memory
>> allocation vs. allocation that sizes just 1-page over the application.
>> >
>> > 1) Can anyone tell me the exact kernel config name that needs to be
>> adjusted for the 38 kernel to set the default memory allocation?
>> >   - Older posts indicate modules like page_alloc2 or Kmalloc2
>> control this so I'm going to investigate these in more detail
>> >   - RTFMing indicate that this might be the area but I don't see it
>> in the 38 version (LTIB or make menucionfig):
>> >   menuconfig -> kernel settings -> general settings, try
>> enabling either the "Permit large allocations" setting, or the
>> "non-power-of-2"
>> >
>> > 2) Historically, we use LTIB to create the kernel.  Does LTIB expose
>> most/all settings of the 2.6.38 kernel?  Can it be out of sync with the
>> make menuconfig uClinus kernel?
>>
>>  Maybe this changed the behaviour you see:
>>
>> commit fc4d5c292b68ef02514d2072dcbf82d090c34875
>> Author: David Howells 
>> Date:   Wed May 6 16:03:05 2009 -0700
>>
>> nommu: make the initial mmap allocation excess behaviour Kconfig
>> configurable
>>
>> NOMMU mmap() has an option controlled by a sysctl variable that
>> determines
>> whether the allocations made by do_mmap_private() should have the
>> excess
>> space trimmed off and returned to the allocator.  Make the initial
>> setting
>> of this variable a Kconfig configuration option.
>>
>> The reason there can be excess space is that the allocator only
>> allocates
>> in power-of-2 size chunks, but mmap()'s can be made in sizes that
>> aren't a
>> power of 2.
>>
>> There are two alternatives:
>>
>>  (1) Keep the excess as dead space.  The dead space then remains
>> unused for the
>>  lifetime of the mapping.  Mappings of shared objects such as
>> libc, ld.so
>>  or busybox's text segment may retain their dead space forever.
>>
>>  (2) Return the excess to the allocator.  This means that the dead
>> space is
>>  limited to less than a page per mapping, but it means that for a
>> transient
>>  process, there's more chance of fragmentation as the excess
>> space may be
>>  reused fairly quickly.
>>
>> During the boot process, a lot of transient processes are created, and
>> this can cause a lot of fragmentation as the pagecache and various
>> slabs
>> grow greatly during this time.
>>
>> By turning off the trimming of excess space during boot and disabling
>> batching of frees, Coldfire can manage to boot.
>>
>> A better way of doing things might be to have /sbin/init turn this
>> option
>> off.  By that point libc, ld.so and init - which are all long-duration
>> processes - have all been loaded and trimmed.
>>
>> Reported-by: Lanttor Guo 
>> Signed-off-by: David Howells 
>> Tested-by: Lanttor Guo 
>> Cc: Greg Ungerer 
>> Signed-off-by: Andrew Morton 
>> Signed-off-by: Linus Torvalds 
>>
>> After all before this commit, trimming after allocating was always done.
>> Now it is only done if you enable this CONFIG, or set the sysctl flag
>> at runtime, which of course affects behaviour for all allocations after
>> you change the setting.
>>
>> --
>> Len Sorensen
>>  ___
>> uClinux-dev mailing list
>> uClinux-dev@uclinux.org
>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>> This message was resent by uclinux-dev@uclinux.org
>> To unsubscribe see:
>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>>
>
>
>
> ___
> uClinux-dev mailing 
> listuClinux-dev@uclinux.orghttp://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev
>
>
>
> ___
> uClinux-dev mailing list
> uC

Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Raju B]

Hi Michael,

  is there any mistakes in coldfire kernel level?. can u please
help me to overcome this issue.

Thanks & Regards,
Raju B


On Wed, Nov 6, 2013 at 3:10 PM, Raju B  wrote:

> Hi Michael,
>
> The ColdFire is 523x and using UART serial interface.
>
> Thanks & regards,
> Raju B
>
>
> On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant wrote:
>
>>
>> Raj,
>>
>> Which ColdFire are you using?
>> Which serial interface are you seeing this with (UART/SPI/I2C/..)?
>>
>> Michael
>>
>>
>> On 11/05/2013 07:40 AM, Raju B wrote:
>>
>>   whenever i am trying to receive data from serial communication
>> continuously in uClinux, I am getting every 10th byte is overwrite by 11
>> byte and so on
>>
>>   Iam using freescale coldfire processor. Could you any body  please help
>> me to resolve this issue.
>>
>>  Thanks & Regards,
>>  Raj
>>
>>
>> On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen <
>> lsore...@csclub.uwaterloo.ca> wrote:
>>
>>> On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote:
>>> > I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale
>>> BSP) and am working to make it run on the 2.6.38 kernel released in the
>>> ColdFire BSP in Feb 2012.  I'm concerned about memory allocation as my
>>> first attempt to run on the 38 kernel appears to be using 2^n memory
>>> allocation vs. allocation that sizes just 1-page over the application.
>>> >
>>> > 1) Can anyone tell me the exact kernel config name that needs to be
>>> adjusted for the 38 kernel to set the default memory allocation?
>>> >   - Older posts indicate modules like page_alloc2 or Kmalloc2
>>> control this so I'm going to investigate these in more detail
>>> >   - RTFMing indicate that this might be the area but I don't see
>>> it in the 38 version (LTIB or make menucionfig):
>>> >   menuconfig -> kernel settings -> general settings, try
>>> enabling either the "Permit large allocations" setting, or the
>>> "non-power-of-2"
>>> >
>>> > 2) Historically, we use LTIB to create the kernel.  Does LTIB expose
>>> most/all settings of the 2.6.38 kernel?  Can it be out of sync with the
>>> make menuconfig uClinus kernel?
>>>
>>>  Maybe this changed the behaviour you see:
>>>
>>> commit fc4d5c292b68ef02514d2072dcbf82d090c34875
>>> Author: David Howells 
>>> Date:   Wed May 6 16:03:05 2009 -0700
>>>
>>> nommu: make the initial mmap allocation excess behaviour Kconfig
>>> configurable
>>>
>>> NOMMU mmap() has an option controlled by a sysctl variable that
>>> determines
>>> whether the allocations made by do_mmap_private() should have the
>>> excess
>>> space trimmed off and returned to the allocator.  Make the initial
>>> setting
>>> of this variable a Kconfig configuration option.
>>>
>>> The reason there can be excess space is that the allocator only
>>> allocates
>>> in power-of-2 size chunks, but mmap()'s can be made in sizes that
>>> aren't a
>>> power of 2.
>>>
>>> There are two alternatives:
>>>
>>>  (1) Keep the excess as dead space.  The dead space then remains
>>> unused for the
>>>  lifetime of the mapping.  Mappings of shared objects such as
>>> libc, ld.so
>>>  or busybox's text segment may retain their dead space forever.
>>>
>>>  (2) Return the excess to the allocator.  This means that the dead
>>> space is
>>>  limited to less than a page per mapping, but it means that for
>>> a transient
>>>  process, there's more chance of fragmentation as the excess
>>> space may be
>>>  reused fairly quickly.
>>>
>>> During the boot process, a lot of transient processes are created,
>>> and
>>> this can cause a lot of fragmentation as the pagecache and various
>>> slabs
>>> grow greatly during this time.
>>>
>>> By turning off the trimming of excess space during boot and disabling
>>> batching of frees, Coldfire can manage to boot.
>>>
>>> A better way of doing things might be to have /sbin/init turn this
>>> option
>>> off.  By that point libc, ld.so and init - which are all
>>> long-duration
>>> processes - have all been loaded and trimmed.
>>>
>>> Reported-by: Lanttor Guo 
>>> Signed-off-by: David Howells 
>>> Tested-by: Lanttor Guo 
>>> Cc: Greg Ungerer 
>>> Signed-off-by: Andrew Morton 
>>> Signed-off-by: Linus Torvalds 
>>>
>>> After all before this commit, trimming after allocating was always done.
>>> Now it is only done if you enable this CONFIG, or set the sysctl flag
>>> at runtime, which of course affects behaviour for all allocations after
>>> you change the setting.
>>>
>>> --
>>> Len Sorensen
>>>  ___
>>> uClinux-dev mailing list
>>> uClinux-dev@uclinux.org
>>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>> This message was resent by uclinux-dev@uclinux.org
>>> To unsubscribe see:
>>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>>>
>>
>>
>>
>> 

Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Michael Durrant]

Raju,

I would expect data overruns causing lost characters if your CPU utilization is 
high and your kernel
driver can't get back to servicing the UART IRQ fast enough.  Your MCF523x part 
appears to have
only a small FIFO buffer (a shift register and 3 receiver registers).   So if 
the data rate is faster than
the kernel can remove the data hardware FIFO it is likely you will miss data 
due to overruns.   So
in your case the 10th character was lost (overwritten) by the next character.  
Sounds like you need
DMA support for the UART you are using or perhaps slow down the incoming data 
or perhaps
turn hardware flow control on.

Michael

On 11/06/2013 04:40 AM, Raju B wrote:

Hi Michael,

The ColdFire is 523x and using UART serial interface.

Thanks & regards,
Raju B


On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant mailto:mdurr...@uclinux.org>> wrote:


Raj,

Which ColdFire are you using?
Which serial interface are you seeing this with (UART/SPI/I2C/..)?

Michael


On 11/05/2013 07:40 AM, Raju B wrote:

whenever i am trying to receive data from serial communication continuously 
in uClinux, I am getting every 10th byte is overwrite by 11 byte and so on

 Iam using freescale coldfire processor. Could you any body  please help me 
to resolve this issue.

Thanks & Regards,
Raj


On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen mailto:lsore...@csclub.uwaterloo.ca>> wrote:

On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote:
> I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale 
BSP) and am working to make it run on the 2.6.38 kernel released in the ColdFire 
BSP in Feb 2012.  I'm concerned about memory allocation as my first attempt to run 
on the 38 kernel appears to be using 2^n memory allocation vs. allocation that 
sizes just 1-page over the application.
>
> 1) Can anyone tell me the exact kernel config name that needs to be 
adjusted for the 38 kernel to set the default memory allocation?
>   - Older posts indicate modules like page_alloc2 or Kmalloc2 
control this so I'm going to investigate these in more detail
>   - RTFMing indicate that this might be the area but I don't see 
it in the 38 version (LTIB or make menucionfig):
>   menuconfig -> kernel settings -> general settings, try enabling either the 
"Permit large allocations" setting, or the "non-power-of-2"
>
> 2) Historically, we use LTIB to create the kernel.  Does LTIB expose 
most/all settings of the 2.6.38 kernel?  Can it be out of sync with the make 
menuconfig uClinus kernel?

Maybe this changed the behaviour you see:

commit fc4d5c292b68ef02514d2072dcbf82d090c34875
Author: David Howells mailto:dhowe...@redhat.com>>
Date:   Wed May 6 16:03:05 2009 -0700

nommu: make the initial mmap allocation excess behaviour Kconfig 
configurable

NOMMU mmap() has an option controlled by a sysctl variable that 
determines
whether the allocations made by do_mmap_private() should have the 
excess
space trimmed off and returned to the allocator.  Make the initial 
setting
of this variable a Kconfig configuration option.

The reason there can be excess space is that the allocator only 
allocates
in power-of-2 size chunks, but mmap()'s can be made in sizes that 
aren't a
power of 2.

There are two alternatives:

 (1) Keep the excess as dead space.  The dead space then remains 
unused for the
 lifetime of the mapping.  Mappings of shared objects such as 
libc, ld.so
 or busybox's text segment may retain their dead space forever.

 (2) Return the excess to the allocator.  This means that the dead 
space is
 limited to less than a page per mapping, but it means that for 
a transient
 process, there's more chance of fragmentation as the excess 
space may be
 reused fairly quickly.

During the boot process, a lot of transient processes are created, 
and
this can cause a lot of fragmentation as the pagecache and various 
slabs
grow greatly during this time.

By turning off the trimming of excess space during boot and 
disabling
batching of frees, Coldfire can manage to boot.

A better way of doing things might be to have /sbin/init turn this 
option
off.  By that point libc, ld.so and init - which are all 
long-duration
processes - have all been loaded and trimmed.

Reported-by: Lanttor Guo mailto:lanttor@freescale.com>>
Signed-off-by: David Howells mailto:dhowe...@redhat.com>>
Tested-by: Lanttor Guo mailto:lanttor@freescale.com>>
Cc: Greg Ungerer mailto:g...@snapgear.com>>
Signed-off-by: Andrew 

Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Raju B]

Hi Michael

Thank You, I will try and get back you.

Thanks & Regards,
Raju


On Thu, Nov 7, 2013 at 10:06 PM, Michael Durrant wrote:

>  Raju,
>
> I would expect data overruns causing lost characters if your CPU
> utilization is high and your kernel
> driver can't get back to servicing the UART IRQ fast enough.  Your MCF523x
> part appears to have
> only a small FIFO buffer (a shift register and 3 receiver registers).   So
> if the data rate is faster than
> the kernel can remove the data hardware FIFO it is likely you will miss
> data due to overruns.   So
> in your case the 10th character was lost (overwritten) by the next
> character.  Sounds like you need
> DMA support for the UART you are using or perhaps slow down the incoming
> data or perhaps
> turn hardware flow control on.
>
> Michael
>
> On 11/06/2013 04:40 AM, Raju B wrote:
>
>   Hi Michael,
>
>  The ColdFire is 523x and using UART serial interface.
>
>  Thanks & regards,
>  Raju B
>
>
>  On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant wrote:
>
>>
>> Raj,
>>
>> Which ColdFire are you using?
>> Which serial interface are you seeing this with (UART/SPI/I2C/..)?
>>
>> Michael
>>
>>
>> On 11/05/2013 07:40 AM, Raju B wrote:
>>
>>   whenever i am trying to receive data from serial communication
>> continuously in uClinux, I am getting every 10th byte is overwrite by 11
>> byte and so on
>>
>>   Iam using freescale coldfire processor. Could you any body  please help
>> me to resolve this issue.
>>
>>  Thanks & Regards,
>>  Raj
>>
>>
>> On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen <
>> lsore...@csclub.uwaterloo.ca> wrote:
>>
>>> On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote:
>>> > I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale
>>> BSP) and am working to make it run on the 2.6.38 kernel released in the
>>> ColdFire BSP in Feb 2012.  I'm concerned about memory allocation as my
>>> first attempt to run on the 38 kernel appears to be using 2^n memory
>>> allocation vs. allocation that sizes just 1-page over the application.
>>> >
>>> > 1) Can anyone tell me the exact kernel config name that needs to be
>>> adjusted for the 38 kernel to set the default memory allocation?
>>> >   - Older posts indicate modules like page_alloc2 or Kmalloc2
>>> control this so I'm going to investigate these in more detail
>>> >   - RTFMing indicate that this might be the area but I don't see
>>> it in the 38 version (LTIB or make menucionfig):
>>> >   menuconfig -> kernel settings -> general settings, try
>>> enabling either the "Permit large allocations" setting, or the
>>> "non-power-of-2"
>>> >
>>> > 2) Historically, we use LTIB to create the kernel.  Does LTIB expose
>>> most/all settings of the 2.6.38 kernel?  Can it be out of sync with the
>>> make menuconfig uClinus kernel?
>>>
>>>  Maybe this changed the behaviour you see:
>>>
>>> commit fc4d5c292b68ef02514d2072dcbf82d090c34875
>>> Author: David Howells 
>>> Date:   Wed May 6 16:03:05 2009 -0700
>>>
>>> nommu: make the initial mmap allocation excess behaviour Kconfig
>>> configurable
>>>
>>> NOMMU mmap() has an option controlled by a sysctl variable that
>>> determines
>>> whether the allocations made by do_mmap_private() should have the
>>> excess
>>> space trimmed off and returned to the allocator.  Make the initial
>>> setting
>>> of this variable a Kconfig configuration option.
>>>
>>> The reason there can be excess space is that the allocator only
>>> allocates
>>> in power-of-2 size chunks, but mmap()'s can be made in sizes that
>>> aren't a
>>> power of 2.
>>>
>>> There are two alternatives:
>>>
>>>  (1) Keep the excess as dead space.  The dead space then remains
>>> unused for the
>>>  lifetime of the mapping.  Mappings of shared objects such as
>>> libc, ld.so
>>>  or busybox's text segment may retain their dead space forever.
>>>
>>>  (2) Return the excess to the allocator.  This means that the dead
>>> space is
>>>  limited to less than a page per mapping, but it means that for
>>> a transient
>>>  process, there's more chance of fragmentation as the excess
>>> space may be
>>>  reused fairly quickly.
>>>
>>> During the boot process, a lot of transient processes are created,
>>> and
>>> this can cause a lot of fragmentation as the pagecache and various
>>> slabs
>>> grow greatly during this time.
>>>
>>> By turning off the trimming of excess space during boot and disabling
>>> batching of frees, Coldfire can manage to boot.
>>>
>>> A better way of doing things might be to have /sbin/init turn this
>>> option
>>> off.  By that point libc, ld.so and init - which are all
>>> long-duration
>>> processes - have all been loaded and trimmed.
>>>
>>> Reported-by: Lanttor Guo 
>>> Signed-off-by: David Howells 
>>> Tested-by: Lanttor Guo 
>>> Cc: Greg Ungerer 
>>> Signed-off-by: Andrew Morton 
>>> Signed-off

Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Raju B]

Hi Michael,

I have tried with baudrate = 9600 and 19200, then it is working fine(i.e
getting data, no overruns). but i want to use high speed(115200). can u
please give any suggestion to over come this.

Thanks &r Regards,
Raju


On Thu, Nov 7, 2013 at 10:06 PM, Michael Durrant wrote:

>  Raju,
>
> I would expect data overruns causing lost characters if your CPU
> utilization is high and your kernel
> driver can't get back to servicing the UART IRQ fast enough.  Your MCF523x
> part appears to have
> only a small FIFO buffer (a shift register and 3 receiver registers).   So
> if the data rate is faster than
> the kernel can remove the data hardware FIFO it is likely you will miss
> data due to overruns.   So
> in your case the 10th character was lost (overwritten) by the next
> character.  Sounds like you need
> DMA support for the UART you are using or perhaps slow down the incoming
> data or perhaps
> turn hardware flow control on.
>
> Michael
>
> On 11/06/2013 04:40 AM, Raju B wrote:
>
>   Hi Michael,
>
>  The ColdFire is 523x and using UART serial interface.
>
>  Thanks & regards,
>  Raju B
>
>
>  On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant wrote:
>
>>
>> Raj,
>>
>> Which ColdFire are you using?
>> Which serial interface are you seeing this with (UART/SPI/I2C/..)?
>>
>> Michael
>>
>>
>> On 11/05/2013 07:40 AM, Raju B wrote:
>>
>>   whenever i am trying to receive data from serial communication
>> continuously in uClinux, I am getting every 10th byte is overwrite by 11
>> byte and so on
>>
>>   Iam using freescale coldfire processor. Could you any body  please help
>> me to resolve this issue.
>>
>>  Thanks & Regards,
>>  Raj
>>
>>
>> On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen <
>> lsore...@csclub.uwaterloo.ca> wrote:
>>
>>> On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote:
>>> > I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale
>>> BSP) and am working to make it run on the 2.6.38 kernel released in the
>>> ColdFire BSP in Feb 2012.  I'm concerned about memory allocation as my
>>> first attempt to run on the 38 kernel appears to be using 2^n memory
>>> allocation vs. allocation that sizes just 1-page over the application.
>>> >
>>> > 1) Can anyone tell me the exact kernel config name that needs to be
>>> adjusted for the 38 kernel to set the default memory allocation?
>>> >   - Older posts indicate modules like page_alloc2 or Kmalloc2
>>> control this so I'm going to investigate these in more detail
>>> >   - RTFMing indicate that this might be the area but I don't see
>>> it in the 38 version (LTIB or make menucionfig):
>>> >   menuconfig -> kernel settings -> general settings, try
>>> enabling either the "Permit large allocations" setting, or the
>>> "non-power-of-2"
>>> >
>>> > 2) Historically, we use LTIB to create the kernel.  Does LTIB expose
>>> most/all settings of the 2.6.38 kernel?  Can it be out of sync with the
>>> make menuconfig uClinus kernel?
>>>
>>>  Maybe this changed the behaviour you see:
>>>
>>> commit fc4d5c292b68ef02514d2072dcbf82d090c34875
>>> Author: David Howells 
>>> Date:   Wed May 6 16:03:05 2009 -0700
>>>
>>> nommu: make the initial mmap allocation excess behaviour Kconfig
>>> configurable
>>>
>>> NOMMU mmap() has an option controlled by a sysctl variable that
>>> determines
>>> whether the allocations made by do_mmap_private() should have the
>>> excess
>>> space trimmed off and returned to the allocator.  Make the initial
>>> setting
>>> of this variable a Kconfig configuration option.
>>>
>>> The reason there can be excess space is that the allocator only
>>> allocates
>>> in power-of-2 size chunks, but mmap()'s can be made in sizes that
>>> aren't a
>>> power of 2.
>>>
>>> There are two alternatives:
>>>
>>>  (1) Keep the excess as dead space.  The dead space then remains
>>> unused for the
>>>  lifetime of the mapping.  Mappings of shared objects such as
>>> libc, ld.so
>>>  or busybox's text segment may retain their dead space forever.
>>>
>>>  (2) Return the excess to the allocator.  This means that the dead
>>> space is
>>>  limited to less than a page per mapping, but it means that for
>>> a transient
>>>  process, there's more chance of fragmentation as the excess
>>> space may be
>>>  reused fairly quickly.
>>>
>>> During the boot process, a lot of transient processes are created,
>>> and
>>> this can cause a lot of fragmentation as the pagecache and various
>>> slabs
>>> grow greatly during this time.
>>>
>>> By turning off the trimming of excess space during boot and disabling
>>> batching of frees, Coldfire can manage to boot.
>>>
>>> A better way of doing things might be to have /sbin/init turn this
>>> option
>>> off.  By that point libc, ld.so and init - which are all
>>> long-duration
>>> processes - have all been loaded and trimmed.
>>>
>>> Reported-by: Lanttor Guo 

Re: [uClinux-dev] 2.6.38 in Freescale Feb 2012 BSP

[Steve deRosier]

I think it was already suggested: you need to enable flow-control.  Either
hardware if you've got the pins setup right on that port or software
(xon/xoff) if you don't.


On Tue, Nov 12, 2013 at 4:11 AM, Raju B  wrote:

> Hi Michael,
>
> I have tried with baudrate = 9600 and 19200, then it is working fine(i.e
> getting data, no overruns). but i want to use high speed(115200). can u
> please give any suggestion to over come this.
>
> Thanks &r Regards,
> Raju
>
>
> On Thu, Nov 7, 2013 at 10:06 PM, Michael Durrant wrote:
>
>>  Raju,
>>
>> I would expect data overruns causing lost characters if your CPU
>> utilization is high and your kernel
>> driver can't get back to servicing the UART IRQ fast enough.  Your
>> MCF523x part appears to have
>> only a small FIFO buffer (a shift register and 3 receiver registers).
>> So if the data rate is faster than
>> the kernel can remove the data hardware FIFO it is likely you will miss
>> data due to overruns.   So
>> in your case the 10th character was lost (overwritten) by the next
>> character.  Sounds like you need
>> DMA support for the UART you are using or perhaps slow down the incoming
>> data or perhaps
>> turn hardware flow control on.
>>
>> Michael
>>
>> On 11/06/2013 04:40 AM, Raju B wrote:
>>
>>   Hi Michael,
>>
>>  The ColdFire is 523x and using UART serial interface.
>>
>>  Thanks & regards,
>>  Raju B
>>
>>
>>  On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant 
>> wrote:
>>
>>>
>>> Raj,
>>>
>>> Which ColdFire are you using?
>>> Which serial interface are you seeing this with (UART/SPI/I2C/..)?
>>>
>>> Michael
>>>
>>>
>>> On 11/05/2013 07:40 AM, Raju B wrote:
>>>
>>>   whenever i am trying to receive data from serial communication
>>> continuously in uClinux, I am getting every 10th byte is overwrite by 11
>>> byte and so on
>>>
>>>   Iam using freescale coldfire processor. Could you any body  please
>>> help me to resolve this issue.
>>>
>>>  Thanks & Regards,
>>>  Raj
>>>
>>>
>>> On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen <
>>> lsore...@csclub.uwaterloo.ca> wrote:
>>>
 On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote:
 > I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale
 BSP) and am working to make it run on the 2.6.38 kernel released in the
 ColdFire BSP in Feb 2012.  I'm concerned about memory allocation as my
 first attempt to run on the 38 kernel appears to be using 2^n memory
 allocation vs. allocation that sizes just 1-page over the application.
 >
 > 1) Can anyone tell me the exact kernel config name that needs to be
 adjusted for the 38 kernel to set the default memory allocation?
 >   - Older posts indicate modules like page_alloc2 or Kmalloc2
 control this so I'm going to investigate these in more detail
 >   - RTFMing indicate that this might be the area but I don't see
 it in the 38 version (LTIB or make menucionfig):
 >   menuconfig -> kernel settings -> general settings, try
 enabling either the "Permit large allocations" setting, or the
 "non-power-of-2"
 >
 > 2) Historically, we use LTIB to create the kernel.  Does LTIB expose
 most/all settings of the 2.6.38 kernel?  Can it be out of sync with the
 make menuconfig uClinus kernel?

  Maybe this changed the behaviour you see:

 commit fc4d5c292b68ef02514d2072dcbf82d090c34875
 Author: David Howells 
 Date:   Wed May 6 16:03:05 2009 -0700

 nommu: make the initial mmap allocation excess behaviour Kconfig
 configurable

 NOMMU mmap() has an option controlled by a sysctl variable that
 determines
 whether the allocations made by do_mmap_private() should have the
 excess
 space trimmed off and returned to the allocator.  Make the initial
 setting
 of this variable a Kconfig configuration option.

 The reason there can be excess space is that the allocator only
 allocates
 in power-of-2 size chunks, but mmap()'s can be made in sizes that
 aren't a
 power of 2.

 There are two alternatives:

  (1) Keep the excess as dead space.  The dead space then remains
 unused for the
  lifetime of the mapping.  Mappings of shared objects such as
 libc, ld.so
  or busybox's text segment may retain their dead space forever.

  (2) Return the excess to the allocator.  This means that the dead
 space is
  limited to less than a page per mapping, but it means that for
 a transient
  process, there's more chance of fragmentation as the excess
 space may be
  reused fairly quickly.

 During the boot process, a lot of transient processes are created,
 and
 this can cause a lot of fragmentation as the pagecache and various
 slabs
 grow greatly during this time.

 By turning off the trimming