Messages in this thread | | | Date | Mon, 16 Aug 2004 06:51:10 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] voluntary-preempt-2.6.8.1-P0 |
| |
* Lee Revell <rlrevell@joe-job.com> wrote:
> This was caused by 'Actions -> Run -> rxvt':
> 0.001ms (+0.000ms): pte_alloc_map (copy_page_range) > 0.205ms (+0.204ms): do_IRQ (common_interrupt)
> 0.228ms (+0.000ms): preempt_schedule (copy_page_range)
> 0.399ms (+0.000ms): preempt_schedule (copy_page_range) > 0.400ms (+0.000ms): check_preempt_timing (touch_preempt_timing)
seems we need a lock-break in the innermost loop of copy_page_range(). That loop processes up to 1024 pages currently, before the lock-break in the outer loop happens. Large GUI processes are more likely to have full 4MB regions mapped & populated.
i suspect you could trigger a similarly bad latency by doing a fork() in mlockall-test.cc - the attached mlockall-test2.cc does this. Do you get bad latencies?
Ingo // here is the code i used to test the mlockall caused xruns #include <sys/mman.h> #include <iostream> #include <sstream> #include <unistd.h>
int main (int argc, char *argv[]) { if (argc < 2) { std::cout << "how many kbytes you want allocated and mlockall'ed?" << std::endl; }
std::stringstream stream(argv[1]); int kbytes; stream >> kbytes; char *mem = new char[kbytes*1024]; std::cout << "filling with 0's" << std::endl; for (int i = 0; i < kbytes*1024; ++i) { mem[i] = 0; }
std::cout << "ok, you want " << kbytes << "kb of memory mlocked. going for it.." << std::endl; int error = mlockall(MCL_CURRENT); if (error != 0) { std::cout << "mlock error" << std::endl; } else { std::cout << "mlock successfull" << std::endl;} fork(); }
| |