From: Mark_H_Johnson@Raytheon.com
To: Ruthiano Simioni Munaretti <ruthiano@exatas.unisinos.br>
Cc: linux-mm@kvack.org, owner-linux-mm@kvack.org, sisopiii-l@cscience.org
Subject: Re: Non-Contiguous Memory Allocation Tests
Date: Wed, 10 Dec 2003 08:42:15 -0600 [thread overview]
Message-ID: <OF3FECDB70.6DC3683E-ON86256DF8.0050199B@raytheon.com> (raw)
>In VGNCA, the main idea is enable/disable interrupts only one time,
reducing
>this overhead. Also, VGNCA allocation/deallocation functions are a little
>more simple, because elimination of unnecessary test conditions in size
>allocation.
>
>Our patch is intended to be a test to check if this could bring enough
>benefits to deserve a more careful implementation. We also included some
code
>to benchmark allocations and deallocations, using the RDTSC instruction.
My only comment about this (and similar "optimizations") is a general
concern about latency. Let's say I have an interactive (or real time)
program running and some other application does one of these non
contiguous memory allocations. Is the time to complete the allocation
bounded? Not apparently since "numpages" is an input to the allocation
routine. There also does not appear to be any code to allow a reschedule
to occur if scheduling is needed. If you are serious about pursuing
something like this, I suggest you review the lock break / preemption
code in the kernel (or in Andrew Morton's low latency patches) for
examples of the required coding style.
--Mark H Johnson
<mailto:Mark_H_Johnson@raytheon.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next reply other threads:[~2003-12-10 14:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-10 14:42 Mark_H_Johnson [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-12-09 13:11 Ruthiano Simioni Munaretti
2003-12-13 2:32 ` Rik van Riel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OF3FECDB70.6DC3683E-ON86256DF8.0050199B@raytheon.com \
--to=mark_h_johnson@raytheon.com \
--cc=linux-mm@kvack.org \
--cc=owner-linux-mm@kvack.org \
--cc=ruthiano@exatas.unisinos.br \
--cc=sisopiii-l@cscience.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox