> Summary is, when I run the app "time test",
>
> on x86:
> real0m0.066s
> user0m0.008s
> sys 0m0.058s
>
> on Blackfin:
> real3m 37.69s
> user0m 0.04s
> sys 3m 37.58s
What would be relevant would be Blackfin with clearing and blackfin
without
> --
On 3/30/07, David Howells <[EMAIL PROTECTED]> wrote:
Aubrey Li <[EMAIL PROTECTED]> wrote:
> Keep the same behave as MMU but with bad performance, or keep the same
> performance as MMU but without the same behave, Which one is more
> important?
The thing to do is to pass a flag to mmap() to supp
Aubrey Li <[EMAIL PROTECTED]> wrote:
> Summary is, when I run the app "time test",
>
> on x86:
> real0m0.066s
> user0m0.008s
> sys 0m0.058s
>
> on Blackfin:
> real3m 37.69s
> user0m 0.04s
> sys 3m 37.58s
That's not a good comparison: you're comparing two different machin
On 3/30/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> I can't find mmap must give zeroed memory in the mmap manual.
> Is there any reason relying on anon mmap() giving zerod memory?
Its how all Unix/Linux like systems behave.
Fair enough.
You have to clear the memory
to something to deal with se
> I can't find mmap must give zeroed memory in the mmap manual.
> Is there any reason relying on anon mmap() giving zerod memory?
Its how all Unix/Linux like systems behave. You have to clear the memory
to something to deal with security on any kind of real system, and zero
is a good a value as an
On 3/30/07, David Howells <[EMAIL PROTECTED]> wrote:
Aubrey Li <[EMAIL PROTECTED]> wrote:
> malloc() allocates size bytes and returns a pointer to the allocated memory.
> The memory is not cleared.
But this is *not* malloc(). It's mmap(). Are you prepared to guarantee that
there are n
Aubrey Li <[EMAIL PROTECTED]> wrote:
> malloc() allocates size bytes and returns a pointer to the allocated memory.
> The memory is not cleared.
But this is *not* malloc(). It's mmap(). Are you prepared to guarantee that
there are no applications out there that don't rely on anon mmap()
On 3/30/07, David Howells <[EMAIL PROTECTED]> wrote:
Wu, Bryan <[EMAIL PROTECTED]> wrote:
> It takes lots of time in malloc()->mmap()->do_mmap_private()->memset(). When
> malloc a big area, memset() the area to zero makes the performance very bad.
Ummm...
How do you then cope with attempting t
Wu, Bryan <[EMAIL PROTECTED]> wrote:
> It takes lots of time in malloc()->mmap()->do_mmap_private()->memset(). When
> malloc a big area, memset() the area to zero makes the performance very bad.
Ummm...
How do you then cope with attempting to run that same application under
MMU-mode Linux? Won'
On 3/29/07, Wu, Bryan <[EMAIL PROTECTED]> wrote:
On architectures with MMU, malloc takes about the same speed,
indepentant of malloc size, while on the Blackfin (NOMMU), as the malloc
size increases, the time that malloc consumes grows
err, this is not the direction we wanted to go ... this
On architectures with MMU, malloc takes about the same speed,
indepentant of malloc size, while on the Blackfin (NOMMU), as the malloc
size increases, the time that malloc consumes grows
This small application, which does a bunch of mallocs, and times them
with gettimeofday():
===
11 matches
Mail list logo
