lkml.org 
[lkml]   [2004]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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();
}

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.331 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site