gcc -Wall -O3 -o pti pti.cand finally run it with./ptiFor my cpu aka Intel i7 4790k, switching to patched kernel, my computer slow down a lot from this generic test. When upgrading to pacthed kernel, you can still disable patch with kernel grub option pti=off. Next tests will be shown with pti=on and pti=off

With pti=off and generic test, my results could be shown below :

12113.571401 seconds With pti=on and generic, we could watch a several regression : 120813.998673 seconds Now to know when rebooting my system, I know if patch is apply or not and before making tests, I will build and run this C code.Simple GIS test : From years now and unfortunately, I fight with ECW files. I have some big ecw which I found far away better in performance in comparison to multiple files like 36GB.But for this test I will use a moderate ECW raster which is an orthophotography of Mauritius Island with 15cm resolution pixel and size of this file is 15 GB and cover 56 x 67 kilometers. Sample overview :

Idea is to create a pretty well compress geotiff (and a good way to switch from ECW to geotiff since Paul Ramsey make a great tutorial about it and it's now embeded in Qgis raster menu ! ) to understand if these kernel patches have influences over a standard GIS tranformation.I use gdal_translate with time command in a bash terminal to benchmark it. Command line is like that :

real 117m4,998suser 107m28,128ssys 0m44,773sResults shiow +/- no difference which demonstrate there is no impact regression on a Gdal GIS usage. Time for this process is big due to usage of JPEG compression which is only single core in gdal. Test is perform on external usb 3.0 2.5" hard drive.I made some others tests with gdalwrap and multithreading option and also there is no significant differences ...CPU / GPU test with blender and generic blenchmark : Finally, I use my computer to render 3D files sometimes and I would like to test CPU and GPU in this test. May be not related but cpu manage (with a small amount) gpu during gpu computation.

With pti on or off I had +/- same results : 45/47s with dual GPU and 2min10 / 2min11

So applying and using patch is recommanded since they publish how to use this leaks but we clearly show that they want to sell new platforms with a great new performances (in fact same as before without KPTI patches).Happy proofing and selling thing but in my case it doesn't matter except with my postgres / postgis database. Does postgres tests made by others with pgbench really perform impact of GIS usage ?!

The above query returns a GeoJSON representation of the summits whose names include “col” and whose elevations are greater than or equal to 3500. The returned features have no geometry and their attributes include “name” and “elevation” only.

Not including the geometry in the features makes the parsing in the browser much faster, so for cases where the geometries aren’t needed this is a big win.

Credits for the “queryable={field}&{field}__{query_op}={value}” syntax goes to FeatureServer!

Pretty cool… But it gets really interesting when repoze.what is added to the picture. For those who don’t know repoze.what, repoze.what is an authorization framework for WSGI applications. repoze.what now provides a Pylons plugin, making it easy to protect controllers and controller actions in a Pylons application. Here’s how our tilecache action can be protected:

With the above, anyone who tries to access /tilecache will have to be granted the tilecache permission. Otherwise, authorization will be denied.

TileCache is secured!

People often want finer-grained authorization, like give certain users access to certain layers. With Pylons’ routing system this can be easily and elegantly achieved using repoze.what, I will show that in a later post.