I guess I'll postpone the likely/unlikely after resynching with Linus
since I'm basically ready to run rsync and I prefer to go sleep early
today and to think about new things tomorrow ;).
I also have a few arguments about the likely/unlikely to solve before
agreeing on it, in particular in all my usages the value will be either
0 or 1 so I don't see why should I tell gcc to do !!, probably it will
be optimized away but I also don't see why should the left term matter
for an "if", the "if" only cares about zero or non zero, so I should be
able to define the fast path with an 1 even if my result is 2, otherwise
it sounds like gcc is doing something strange.
> I can't measure any obviously new causes of latency in your
> VM. It's nice that you've paid attention to this in various
> places.
thanks.
> The main culprits now are the file IO and dirty buffer writeout paths:
> up to fifty milliseconds in each.
>
> I suggest you stick scheduling points in generic_file_read(),
> generic_file_write() and write_locked_buffers() and then dispose
> of the copy-user-latency patch from -aa kernels.
Yes, I pretty much agree on such change, I remeber you just pointed out
once. It's postponed to tomorrow too ;).
At the moment I just care to post the vm fixes against pre11 plain in
order to possibly get some feedback on it while I sleep :)
> With the above fixed, the main source of latency is
> /proc/meminfo->si_swapinfo(). It's about five milliseconds per gig
> of swap, which isn't too bad. But it's directly invokable by
> userspace (ie: /usr/bin/top) and really should be made less dumb.
ok.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/