- linaro-kernel - lists.linaro.org

Regards Of Firmware For Versatile Express TC2 board

by Leo Yan

hi Nico & all, For in my previous email, i get to know if we want to boot up successfully with Nico's latest big.LITTLE SMP related patches (these patches can get from landing team's tracking-armlt-tc2-pm branch), we need update VE's firmware, otherwise the system ONLY can boot up the first one core. For VE DVD v5.0 has updated the firmware files, we tried it but still cannot bootup successfully, below are the firmware infos now we are using: V2P-CA15_A7 DCC bios: dbb_v107.ebf; V2M-P1 MCC bios: mbb_v311.ebf; V2M-P1 Bootmonoitor: bm_v517r.axf; so i want to confirm which firmwares' version can match with Nico's patches? Or there have special setting/configuration for the boot monitor? Any suggestion is welcome and appreciate. -- Thx, Leo Yan

12 years, 11 months

2
2
0 0

Crash on Panda using kernel 3.7-rc6

by kasi viswanathan

Hi, I booted the kernel image compiled from linux-linaro-3.7-rc6-2012.11 and i got this crash. Pls let me know how can i fix it or is there any patch already availabe Uncompressing Linux... done, booting the kernel. [ 0.000000] Booting Linux on physical CPU 0 [ 0.000000] Linux version 3.7.0-rc6 (root@kasi) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP Thu Dec 20 08:31:16 IST 2012 [ 0.000000] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: OMAP4 Panda board [ 0.000000] Reserving 16777216 bytes SDRAM for VRAM [ 0.000000] Memory policy: ECC disabled, Data cache writealloc [ 0.000000] On node 0 totalpages: 126720 [ 0.000000] free_area_init_node: node 0, pgdat c07e8b40, node_mem_map c0d47000 [ 0.000000] Normal zone: 1024 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 125696 pages, LIFO batch:31 [ 0.000000] OMAP4430 ES2.2 [ 0.000000] PERCPU: Embedded 9 pages/cpu @c114f000 s13120 r8192 d15552 u36864 [ 0.000000] pcpu-alloc: s13120 r8192 d15552 u36864 alloc=9*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 125696 [ 0.000000] Kernel command line: console=ttyO2,115200n8 vram=16M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Memory: 495MB = 495MB total [ 0.000000] Memory: 488684k/488684k available, 35604k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xe0800000 - 0xff000000 ( 488 MB) [ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc070d278 (7189 kB) [ 0.000000] .init : 0xc070e000 - 0xc075f340 ( 325 kB) [ 0.000000] .data : 0xc0760000 - 0xc07ebdd0 ( 560 kB) [ 0.000000] .bss : 0xc07ebdf4 - 0xc0d46804 (5483 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [ 0.000000] OMAP clocksource: 32k_counter at 32768 Hz [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.000000] ... MAX_LOCK_DEPTH: 48 [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 [ 0.000000] ... CLASSHASH_SIZE: 4096 [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 [ 0.000000] ... CHAINHASH_SIZE: 16384 [ 0.000000] memory used by lock dependency info: 3695 kB [ 0.000000] per task-struct memory footprint: 1152 bytes [ 0.001098] Calibrating delay loop... [ 0.007904] BUG: spinlock bad magic on CPU#0, swapper/0/0 [ 0.007965] lock: atomic64_lock+0xc0/0x400, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 [ 0.008026] [<c001ccfc>] (unwind_backtrace+0x0/0xf4) from [<c02eba20>] (do_raw_spin_lock+0x1b8/0x1f8) [ 0.008087] [<c02eba20>] (do_raw_spin_lock+0x1b8/0x1f8) from [<c0521a6c>] (_raw_spin_lock_irqsave+0x4c/0x58) [ 0.008117] [<c0521a6c>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c02f715c>] (atomic64_read+0x28/0x48) [ 0.008148] [<c02f715c>] (atomic64_read+0x28/0x48) from [<c007e1c0>] (update_cfs_rq_blocked_load+0x54/0x11c) [ 0.008148] [<c007e1c0>] (update_cfs_rq_blocked_load+0x54/0x11c) from [<c007e50c>] (task_tick_fair+0x284/0x8b0) [ 0.008209] [<c007e50c>] (task_tick_fair+0x284/0x8b0) from [<c007b0dc>] (scheduler_tick+0xd8/0x140) [ 0.008239] [<c007b0dc>] (scheduler_tick+0xd8/0x140) from [<c0056134>] (update_process_times+0x58/0x68) [ 0.008270] [<c0056134>] (update_process_times+0x58/0x68) from [<c0093910>] (tick_periodic+0x48/0xc4) [ 0.008300] [<c0093910>] (tick_periodic+0x48/0xc4) from [<c00939b0>] (tick_handle_periodic+0x24/0x98) [ 0.008331] [<c00939b0>] (tick_handle_periodic+0x24/0x98) from [<c002a104>] (omap2_gp_timer_interrupt+0x24/0x34) [ 0.008361] [<c002a104>] (omap2_gp_timer_interrupt+0x24/0x34) from [<c00acafc>] (handle_irq_event_percpu+0x64/0x244) [ 0.008392] [<c00acafc>] (handle_irq_event_percpu+0x64/0x244) from [<c00acd18>] (handle_irq_event+0x3c/0x5c) [ 0.008422] [<c00acd18>] (handle_irq_event+0x3c/0x5c) from [<c00af8f4>] (handle_fasteoi_irq+0x98/0x13c) [ 0.008422] [<c00af8f4>] (handle_fasteoi_irq+0x98/0x13c) from [<c00aca88>] (generic_handle_irq+0x28/0x30) [ 0.008483] [<c00aca88>] (generic_handle_irq+0x28/0x30) from [<c00154e0>] (handle_IRQ+0x4c/0xac) [ 0.008514] [<c00154e0>] (handle_IRQ+0x4c/0xac) from [<c00084c4>] (gic_handle_irq+0x2c/0x60) [ 0.008544] [<c00084c4>] (gic_handle_irq+0x2c/0x60) from [<c0522364>] (__irq_svc+0x44/0x5c) [ 0.008544] Exception stack(0xc0761f20 to 0xc0761f68) [ 0.008575] 1f20: 0000001a 00000001 c07620c0 ffff6a00 00000000 00000000 c07ebe8c c07620c0 [ 0.008575] 1f40: ffff6a00 c07620c0 00000000 00000000 00000001 c0761f68 c051ab3c c051ab50 [ 0.008575] 1f60: 60000153 ffffffff [ 0.008636] [<c0522364>] (__irq_svc+0x44/0x5c) from [<c051ab50>] (calibrate_delay+0x3a8/0x550) [ 0.008666] [<c051ab50>] (calibrate_delay+0x3a8/0x550) from [<c070e6cc>] (start_kernel+0x268/0x2fc) [ 0.008697] [<c070e6cc>] (start_kernel+0x268/0x2fc) from [<80008078>] (0x80008078) [ 0.101379] 2007.19 BogoMIPS (lpj=7839744) [ 0.101379] pid_max: default: 32768 minimum: 301 [ 0.101867] Security Framework initialized [ 0.102081] Mount-cache hash table entries: 512 [ 0.103698] CPU: Testing write buffer coherency: ok [ 0.104339] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.104675] Setting up static identity map for 0x80527778 - 0x805277e8 [ 0.104736] L310 cache controller enabled [ 0.104736] l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x7e470000, Cache size: 1048576 B [ 0.107269] CPU1: Booted secondary processor [ 0.174926] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.175018] Brought up 2 CPUs [ 0.175018] SMP: Total of 2 processors activated (4022.78 BogoMIPS). [ 0.175079] CPU0 packing on CPU-1 [ 0.175109] CPU1 packing on CPU-1 [ 0.179840] ttyO2 used as console in debug mode: uart2 clocks will not be gated [ 0.187591] omap_hwmod: l3_instr: _wait_target_disable failed [ 0.242126] pinctrl core: initialized pinctrl subsystem [ 0.243072] regulator-dummy: no parameters [ 0.243499] NET: Registered protocol family 16 [ 0.244873] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.245544] omap-gpmc omap-gpmc: GPMC revision 6.0 [ 0.248992] gpiochip_add: registered GPIOs 0 to 31 on device: gpio [ 0.249084] OMAP GPIO hardware version 0.1 [ 0.249664] gpiochip_add: registered GPIOs 32 to 63 on device: gpio [ 0.250335] gpiochip_add: registered GPIOs 64 to 95 on device: gpio [ 0.250976] gpiochip_add: registered GPIOs 96 to 127 on device: gpio [ 0.251617] gpiochip_add: registered GPIOs 128 to 159 on device: gpio [ 0.252288] gpiochip_add: registered GPIOs 160 to 191 on device: gpio [ 0.254394] omap_mux_init: Add partition: #1: core, flags: 2 [ 0.255462] omap_mux_init: Add partition: #2: wkup, flags: 2 [ 0.255706] _omap_mux_get_by_name: Could not find signal sys_nirq [ 0.255737] _omap_mux_get_by_name: Could not find signal sys_nirq [ 0.258056] _omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx [ 0.258087] _omap_mux_get_by_name: Could not find signal uart1_rx.uart1_rx [ 0.285980] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers. [ 0.286010] hw-breakpoint: maximum watchpoint size is 4 bytes. [ 0.291900] OMAP DMA hardware revision 0.0 [ 0.294128] ARM PMU: not yet supported on OMAP4430 due to missing CTI driver [ 0.312683] bio: create slab <bio-0> at 0 [ 0.340423] omap-dma-engine omap-dma-engine: OMAP DMA engine driver [ 0.340789] vwl1271: 1800 mV [ 0.342712] SCSI subsystem initialized [ 0.343963] usbcore: registered new interface driver usbfs [ 0.344146] usbcore: registered new interface driver hub [ 0.344421] usbcore: registered new device driver usb [ 0.356689] Skipping twl internal clock init and using bootloader value (unknown osc rate) [ 0.357574] twl 1-0048: PIH (irq 39) chaining IRQs 418..438 [ 0.358459] VUSB: 3300 mV normal standby [ 0.359008] vdd_mpu: 500 <--> 1500 mV normal [ 0.359466] vdd_iva: 500 <--> 1500 mV normal [ 0.359985] vdd_core: 500 <--> 1500 mV normal [ 0.360717] V1V8: 1800 mV normal standby [ 0.361236] V2V1: 2100 mV normal standby [ 0.361907] VMMC: 1200 <--> 3000 mV at 3000 mV normal standby [ 0.362762] VPP: 1800 <--> 2500 mV at 1900 mV normal standby [ 0.363677] VCXIO: 1800 mV normal standby [ 0.363708] VCXIO: supplied by V2V1 [ 0.364868] VDAC: 1800 mV normal standby [ 0.364898] VDAC: supplied by V2V1 [ 0.365875] VAUX2_6030: 1200 <--> 2800 mV at 1800 mV normal standby [ 0.366668] VAUX3_6030: 1000 <--> 3000 mV at 1200 mV normal standby [ 0.367553] VANA: 2100 mV normal standby [ 0.367889] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 400 kHz [ 0.378723] omap_i2c omap_i2c.2: bus 2 rev2.4.0 at 400 kHz [ 0.394348] omap_i2c omap_i2c.3: bus 3 rev2.4.0 at 100 kHz [ 0.409698] omap_i2c omap_i2c.4: bus 4 rev2.4.0 at 400 kHz [ 0.411407] Switching to clocksource 32k_counter [ 0.447662] NET: Registered protocol family 2 [ 0.448364] TCP established hash table entries: 16384 (order: 5, 131072 bytes) [ 0.448699] TCP bind hash table entries: 16384 (order: 7, 589824 bytes) [ 0.449951] TCP: Hash tables configured (established 16384 bind 16384) [ 0.450103] TCP: reno registered [ 0.450134] UDP hash table entries: 256 (order: 2, 20480 bytes) [ 0.450195] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) [ 0.450653] NET: Registered protocol family 1 [ 0.451110] RPC: Registered named UNIX socket transport module. [ 0.451110] RPC: Registered udp transport module. [ 0.451110] RPC: Registered tcp transport module. [ 0.451110] RPC: Registered tcp NFSv4.1 backchannel transpo

12 years, 11 months

2
1
0 0

[ACTIVITY] (John Stultz) Dec 17-21

by John Stultz

=== Highlights === * More discussions w/ Zach kernel tree mgmt stuff * Minchan sent v4 of his volatile anon vma patch, and I took an initial look. * Worked with Dmitry's ashmem unit test, researched ioctl numbering issue. * Reviewed Serban's patch and provided feedback * Updated linaro.android tree w/ fixes required for Tushar as well as cpufreq updates === Plans === * Holiday break. Hope everyone has a happy new year! === Issues === * NA

12 years, 12 months

1
0
0 0

(Dong Aisheng) 2012-11-10 - 2012-12-17

by Dong Aisheng

=== Issues === * Took the whole week leave to take of my family in hospital. Backed to work today and then possibly will take leave on 12/20 and 12/21 again since my sister has a surgical operation on that day. <http://dict.baidu.com/s?wd=surgical%20operation>

12 years, 12 months

1
0
0 0

[ACTIVITY] (Rajanikanth H V) 2012-12-10 to 2012-12-14

by Rajanikanth HV

==== Activity Summary ==== * Discussion with ShawnGuo regarding runtime size verification on i.MX platform. ShawnGuo communicated first cut "size data" information about modules, however "change in procedure" and verification on 3.7 kernel needs to be carried out. I have communicated the same. * Finalized runtime data size information on vexpress platform, will be updating in google docs. * OMAP Setup is made ready to verify runtime size information however multiplatform config is not supported and verification on OMAP is currently pushed down in the priority, updated the blueprint accordingly. * Runtime size information on Snowball/U8500: setup to verify runtime sze information is ready, verifying on 3.7 kernel ==== Plan ==== * continue to work on runtime size information across I.MX and u8500 platform * root cause Ethernet issue ==== Issues ==== 0.5 day leave

13 years

1
0
0 0

[ACTIVITY] (John Stultz) Dec 10-14

by John Stultz

=== Highlights === * Lots of discussions w/ Zach/Deepak on kernel tree mgmt stuff * Minchan sent v3 of his volatile anon vma patch, and I reviewed and pointed out hole in the semantics * Started working on integrating the ashmem driver with the volatile anon vma patch, but its ending up being not as trivial as I hoped. * Community discussions about RTCs and persistent_clock interfaces === Plans === * Continue hacking on the vma/madvise approach to volatile ranges. * Likely more talks w/ Zach :) * Prep for holiday break === Issues === * NA

13 years

1
0
0 0

[ACTIVITY] (Ulf Hansson) 2012-12-08 - 2012-12-14

by Ulf Hansson

== Ulf Hansson == === Highlights === Storage: * Acked patches on mmc-list related to SDIO suspend/resume issues. * Reviewed patches on mmc-list for Idle time BKOPS. * Acked patches on mmc-list for fixing signal voltage switch procedure for UHS mode. * Co-operated with Lee Jones to help out in move away from using the mmci host driver "ios_handler" (ux500 platform callback). * Sent patches for discussion for mmci host driver, especially with regards to power management. Clk: * Acked patches from Mike Turquette on clk framework. === Plans === Storage: * Push patches for mmci host driver to support for UHS cards. * Push patches for mmci host driver to further extend the power management support. * Push patches for mmci host driver to add new features like CMD23 support and more. * Follow up on Idle time BKOPS patches on mmc list. Clk: * Send patch/rfc for clk framework, to make an unsued clk unprepared at late_init. * Add support for new clk-types in abx500 clock driver for the ux500 platform. === Issues === * Been trying for several month to get a hold of eMMC 4.5 device with an SD-card adapter. Extremely important for the storage work in Linaro to fully test eMMC4.5 features. It seems almost impossible. Kind regards Ulf Hansson

13 years

1
0
0 0

Questions For CCI-400's Non-secure Access For big.LITTLE MP

by Leo Yan

hi, i saw Nico's git for the developing the big.LITTLE's cluster power control for MP. In the kernel code. the cluster's first man need enable the CCI's port and snooping for the cluster in non-secure world; In CCI-400's spec, it says need to set the Secure Access Register (0x90008) bit 0 so that we can enable non-secure access to CCI-400 registers. On fast model, i added the code in boot-wrapper to set bit_0 for CCI's Secure Access Register; but after set this bit, the boot-wrapper code cannot change to hypervisor mode successfully. On fast model, can we use CCI's secure access register? Current i use the fast model version is: FE000-KT-00002-r7p1-80rel0.tgz, so if it's related with the fast model's version? Also, could u kindly point out there have boot-swapper's git for reference? -- Thx, Leo Yan

13 years

2
8
0 0

[RFC v2] Add mempressure cgroup

by Anton Vorontsov

The main changes for the mempressure cgroup: - Added documentation, describes APIs and the purpose; - Implemented shrinker interface, this is based on Andrew's idea and supersedes my "balance" level idea; - The shrinker interface comes with a stress-test utility, that is what Andrew was also asking for. A simple app that we can run and see if the thing works as expected; - Added reclaimer's target_mem_cgroup handling; - As promised, added support for multiple listeners, and fixed some other comments on the previous RFC. Just for the reference, the first mempressure RFC: http://lkml.org/lkml/2012/11/28/109 Signed-off-by: Anton Vorontsov <anton.vorontsov(a)linaro.org> --- Documentation/cgroups/mempressure.txt | 89 ++++++ Documentation/cgroups/mempressure_test.c | 209 +++++++++++++ include/linux/cgroup_subsys.h | 6 + include/linux/vmstat.h | 11 + init/Kconfig | 12 + mm/Makefile | 1 + mm/mempressure.c | 488 +++++++++++++++++++++++++++++++ mm/vmscan.c | 4 + 8 files changed, 820 insertions(+) create mode 100644 Documentation/cgroups/mempressure.txt create mode 100644 Documentation/cgroups/mempressure_test.c create mode 100644 mm/mempressure.c diff --git a/Documentation/cgroups/mempressure.txt b/Documentation/cgroups/mempressure.txt new file mode 100644 index 0000000..913accc --- /dev/null +++ b/Documentation/cgroups/mempressure.txt @@ -0,0 +1,89 @@ + Memory pressure cgroup +~~~~~~~~~~~~~~~~~~~~~~~~~~ + Before using the mempressure cgroup, make sure you have it mounted: + + # cd /sys/fs/cgroup/ + # mkdir mempressure + # mount -t cgroup cgroup ./mempressure -o mempressure + + After that, you can use the following files: + + /sys/fs/cgroup/.../mempressure.shrinker +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + The file implements userland shrinker (memory reclaimer) interface, so + that the kernel can ask userland to help with the memory reclaiming + process. + + There are two basic concepts: chunks and chunks' size. The program must + tell the kernel the granularity of its allocations (chunk size) and the + number of reclaimable chunks. The granularity may be not 100% accurate, + but the more it is accurate, the better. I.e. suppose the application + has 200 page renders cached (but not displayed), 1MB each. So the chunk + size is 1MB, and the number of chunks is 200. + + The granularity is specified during shrinker registration (i.e. via + argument to the event_control cgroup file; and it is OK to register + multiple shrinkers for different granularities). The number of + reclaimable chunks is specified by writing to the mempressure.shrinker + file. + + The notification comes through the eventfd() interface. Upon the + notification, a read() from the eventfd returns the number of chunks to + reclaim (free). + + It is assumed that the application will free the specified amount of + chunks before reading from the eventfd again. If that is not the case, + suppose the program was not able to reclaim the chunks, then application + should re-add the amount of chunks by writing to the + mempressure.shrinker file (otherwise the chunks won't be accounted by + the kernel, since it assumes that they were reclaimed). + + Event control: + Used to setup shrinker events. There is only one argument for the + event control: chunk size in bytes. + Read: + Not implemented. + Write: + Writes must be in "<eventfd> <number of chunks>" format. Positive + numbers increment the internal counter, negative numbers decrement it + (but the kernel prevents the counter from falling down below zero). + Test: + See mempressure_test.c + + /sys/fs/cgroup/.../mempressure.level +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + Instead of working on the bytes level (like shrinkers), one may decide + to maintain the interactivity/memory allocation cost. + + For this, the cgroup has memory pressure level notifications, and the + levels are defined like this: + + The "low" level means that the system is reclaiming memory for new + allocations. Monitoring reclaiming activity might be useful for + maintaining overall system's cache level. Upon notification, the program + (typically "Activity Manager") might analyze vmstat and act in advance + (i.e. prematurely shutdown unimportant services). + + The "medium" level means that the system is experiencing medium memory + pressure, there is some mild swapping activity. Upon this event + applications may decide to free any resources that can be easily + reconstructed or re-read from a disk. Note that for a fine-grained + control, you should probably use the shrinker interface, as described + above. + + The "oom" level means that the system is actively thrashing, it is about + to out of memory (OOM) or even the in-kernel OOM killer is on its way to + trigger. Applications should do whatever they can to help the system. + + Event control: + Is used to setup an eventfd with a level threshold. The argument to + the event control specifies the level threshold. + Read: + Reads mempory presure levels: low, medium or oom. + Write: + Not implemented. + Test: + To set up a notification: + + # cgroup_event_listener ./mempressure.level low + ("low", "medium", "oom" are permitted.) diff --git a/Documentation/cgroups/mempressure_test.c b/Documentation/cgroups/mempressure_test.c new file mode 100644 index 0000000..9747fd6 --- /dev/null +++ b/Documentation/cgroups/mempressure_test.c @@ -0,0 +1,209 @@ +/* + * mempressure shrinker test + * + * Copyright 2012 Linaro Ltd. + * Anton Vorontsov <anton.vorontsov(a)linaro.org> + * + * It is pretty simple: we create two threads, the first one constantly + * tries to allocate memory (more than we physically have), the second + * thread listens to the kernel shrinker notifications and frees asked + * amount of chunks. When we allocate more than available RAM, the two + * threads start to fight. Idially, we should not OOM (but if we reclaim + * slower than we allocate, things might OOM). Also, ideally we should not + * grow swap too much. + * + * The test accepts no arguments, so you can just run it and observe the + * output and memory usage (e.g. 'watch -n 0.2 free -m'). Upon ctrl+c, the + * test prints total amount of bytes we helped to reclaim. + * + * Compile with -pthread. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#define _GNU_SOURCE +#include <stdio.h> +#include <stdlib.h> +#include <stdint.h> +#include <stdbool.h> +#include <unistd.h> +#include <string.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <pthread.h> +#include <signal.h> +#include <errno.h> +#include <sys/eventfd.h> +#include <sys/sysinfo.h> + +#define CG "/sys/fs/cgroup/mempressure" +#define CG_EVENT_CONTROL (CG "/cgroup.event_control") +#define CG_SHRINKER (CG "/mempressure.shrinker") + +#define CHUNK_SIZE (1 * 1024 * 1024) + +static size_t num_chunks; + +static void **chunks; +static pthread_mutex_t *locks; +static int efd; +static int sfd; + +static inline void pabort(bool f, int code, const char *str) +{ + if (!f) + return; + perror(str); + printf("(%d)\n", code); + abort(); +} + +static void init_shrinker(void) +{ + int cfd; + int ret; + char *str; + + cfd = open(CG_EVENT_CONTROL, O_WRONLY); + pabort(cfd < 0, cfd, CG_EVENT_CONTROL); + + sfd = open(CG_SHRINKER, O_RDWR); + pabort(sfd < 0, sfd, CG_SHRINKER); + + efd = eventfd(0, 0); + pabort(efd < 0, efd, "eventfd()"); + + ret = asprintf(&str, "%d %d %d\n", efd, sfd, CHUNK_SIZE); + printf("%s\n", str); + pabort(ret == -1, ret, "control string"); + + ret = write(cfd, str, ret + 1); + pabort(ret == -1, ret, "write() to event_control"); +} + +static void add_reclaimable(int chunks) +{ + int ret; + char *str; + + ret = asprintf(&str, "%d %d\n", efd, CHUNK_SIZE); + pabort(ret == -1, ret, "add_reclaimable, asprintf"); + + ret = write(sfd, str, ret + 1); + pabort(ret <= 0, ret, "add_reclaimable, write"); +} + +static int chunks_to_reclaim(void) +{ + uint64_t n = 0; + int ret; + + ret = read(efd, &n, sizeof(n)); + pabort(ret <= 0, ret, "read() from eventfd"); + + printf("%d chunks to reclaim\n", (int)n); + + return n; +} + +static unsigned int reclaimed; + +static void print_stats(int signum) +{ + printf("\nTOTAL: helped to reclaim %d chunks (%d MB)\n", + reclaimed, reclaimed * CHUNK_SIZE / 1024 / 1024); + exit(0); +} + +static void *shrinker_thr_fn(void *arg) +{ + puts("shrinker thread started"); + + sigaction(SIGINT, &(struct sigaction){.sa_handler = print_stats}, NULL); + + while (1) { + unsigned int i = 0; + int n; + + n = chunks_to_reclaim(); + + reclaimed += n; + + while (n) { + pthread_mutex_lock(&locks[i]); + if (chunks[i]) { + free(chunks[i]); + chunks[i] = NULL; + n--; + } + pthread_mutex_unlock(&locks[i]); + + i = (i + 1) % num_chunks; + } + } + return NULL; +} + +static void consume_memory(void) +{ + unsigned int i = 0; + unsigned int j = 0; + + puts("consuming memory..."); + + while (1) { + pthread_mutex_lock(&locks[i]); + if (!chunks[i]) { + chunks[i] = malloc(CHUNK_SIZE); + pabort(!chunks[i], 0, "chunks alloc failed"); + memset(chunks[i], 0, CHUNK_SIZE); + j++; + } + pthread_mutex_unlock(&locks[i]); + + if (j >= num_chunks / 10) { + add_reclaimable(num_chunks / 10); + printf("added %d reclaimable chunks\n", j); + j = 0; + } + + i = (i + 1) % num_chunks; + } +} + +int main(int argc, char *argv[]) +{ + int ret; + int i; + pthread_t shrinker_thr; + struct sysinfo si; + + ret = sysinfo(&si); + pabort(ret != 0, ret, "sysinfo()"); + + num_chunks = (si.totalram + si.totalswap) * si.mem_unit / 1024 / 1024; + + chunks = malloc(sizeof(*chunks) * num_chunks); + locks = malloc(sizeof(*locks) * num_chunks); + pabort(!chunks || !locks, ENOMEM, NULL); + + init_shrinker(); + + for (i = 0; i < num_chunks; i++) { + ret = pthread_mutex_init(&locks[i], NULL); + pabort(ret != 0, ret, "pthread_mutex_init"); + } + + ret = pthread_create(&shrinker_thr, NULL, shrinker_thr_fn, NULL); + pabort(ret != 0, ret, "pthread_create(shrinker)"); + + consume_memory(); + + ret = pthread_join(shrinker_thr, NULL); + pabort(ret != 0, ret, "pthread_join(shrinker)"); + + return 0; +} diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h index f204a7a..b9802e2 100644 --- a/include/linux/cgroup_subsys.h +++ b/include/linux/cgroup_subsys.h @@ -37,6 +37,12 @@ SUBSYS(mem_cgroup) /* */ +#if IS_SUBSYS_ENABLED(CONFIG_CGROUP_MEMPRESSURE) +SUBSYS(mpc_cgroup) +#endif + +/* */ + #if IS_SUBSYS_ENABLED(CONFIG_CGROUP_DEVICE) SUBSYS(devices) #endif diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h index 92a86b2..3f7f7d2 100644 --- a/include/linux/vmstat.h +++ b/include/linux/vmstat.h @@ -10,6 +10,17 @@ extern int sysctl_stat_interval; +struct mem_cgroup; +#ifdef CONFIG_CGROUP_MEMPRESSURE +extern void vmpressure(struct mem_cgroup *memcg, + ulong scanned, ulong reclaimed); +extern void vmpressure_prio(struct mem_cgroup *memcg, int prio); +#else +static inline void vmpressure(struct mem_cgroup *memcg, + ulong scanned, ulong reclaimed) {} +static inline void vmpressure_prio(struct mem_cgroup *memcg, int prio) {} +#endif + #ifdef CONFIG_VM_EVENT_COUNTERS /* * Light weight per cpu counter implementation. diff --git a/init/Kconfig b/init/Kconfig index 6fdd6e3..5c308be 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -826,6 +826,18 @@ config MEMCG_KMEM the kmem extension can use it to guarantee that no group of processes will ever exhaust kernel resources alone. +config CGROUP_MEMPRESSURE + bool "Memory pressure monitor for Control Groups" + help + The memory pressure monitor cgroup provides a facility for + userland programs so that they could easily assist the kernel + with the memory management. This includes simple memory pressure + notifications and a full-fledged userland reclaimer. + + For more information see Documentation/cgroups/mempressure.txt + + If unsure, say N. + config CGROUP_HUGETLB bool "HugeTLB Resource Controller for Control Groups" depends on RESOURCE_COUNTERS && HUGETLB_PAGE && EXPERIMENTAL diff --git a/mm/Makefile b/mm/Makefile index 6b025f8..40cee19 100644 --- a/mm/Makefile +++ b/mm/Makefile @@ -50,6 +50,7 @@ obj-$(CONFIG_MIGRATION) += migrate.o obj-$(CONFIG_QUICKLIST) += quicklist.o obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o obj-$(CONFIG_MEMCG) += memcontrol.o page_cgroup.o +obj-$(CONFIG_CGROUP_MEMPRESSURE) += mempressure.o obj-$(CONFIG_CGROUP_HUGETLB) += hugetlb_cgroup.o obj-$(CONFIG_MEMORY_FAILURE) += memory-failure.o obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o diff --git a/mm/mempressure.c b/mm/mempressure.c new file mode 100644 index 0000000..e39a33d --- /dev/null +++ b/mm/mempressure.c @@ -0,0 +1,488 @@ +/* + * Linux VM pressure + * + * Copyright 2012 Linaro Ltd. + * Anton Vorontsov <anton.vorontsov(a)linaro.org> + * + * Based on ideas from Andrew Morton, David Rientjes, KOSAKI Motohiro, + * Leonid Moiseichuk, Mel Gorman, Minchan Kim and Pekka Enberg. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include <linux/cgroup.h> +#include <linux/fs.h> +#include <linux/sched.h> +#include <linux/mm.h> +#include <linux/vmstat.h> +#include <linux/eventfd.h> +#include <linux/swap.h> +#include <linux/printk.h> + +static void mpc_vmpressure(struct mem_cgroup *memcg, ulong s, ulong r); + +/* + * Generic VM Pressure routines (no cgroups or any other API details) + */ + +/* + * The window size is the number of scanned pages before we try to analyze + * the scanned/reclaimed ratio (or difference). + * + * It is used as a rate-limit tunable for the "low" level notification, + * and for averaging medium/oom levels. Using small window sizes can cause + * lot of false positives, but too big window size will delay the + * notifications. + * + * The same window size also used for the shrinker, so be aware. It might + * be a good idea to derive the window size from the machine size, similar + * to what we do for the vmstat. + */ +static const uint vmpressure_win = SWAP_CLUSTER_MAX * 16; +static const uint vmpressure_level_med = 60; +static const uint vmpressure_level_oom = 99; +static const uint vmpressure_level_oom_prio = 4; + +enum vmpressure_levels { + VMPRESSURE_LOW = 0, + VMPRESSURE_MEDIUM, + VMPRESSURE_OOM, + VMPRESSURE_NUM_LEVELS, +}; + +static const char *vmpressure_str_levels[] = { + [VMPRESSURE_LOW] = "low", + [VMPRESSURE_MEDIUM] = "medium", + [VMPRESSURE_OOM] = "oom", +}; + +static enum vmpressure_levels vmpressure_level(uint pressure) +{ + if (pressure >= vmpressure_level_oom) + return VMPRESSURE_OOM; + else if (pressure >= vmpressure_level_med) + return VMPRESSURE_MEDIUM; + return VMPRESSURE_LOW; +} + +static ulong vmpressure_calc_level(uint win, uint s, uint r) +{ + ulong p; + + if (!s) + return 0; + + /* + * We calculate the ratio (in percents) of how many pages were + * scanned vs. reclaimed in a given time frame (window). Note that + * time is in VM reclaimer's "ticks", i.e. number of pages + * scanned. This makes it possible to set desired reaction time + * and serves as a ratelimit. + */ + p = win - (r * win / s); + p = p * 100 / win; + + pr_debug("%s: %3lu (s: %6u r: %6u)\n", __func__, p, s, r); + + return vmpressure_level(p); +} + +void vmpressure(struct mem_cgroup *memcg, ulong scanned, ulong reclaimed) +{ + if (!scanned) + return; + mpc_vmpressure(memcg, scanned, reclaimed); +} + +void vmpressure_prio(struct mem_cgroup *memcg, int prio) +{ + if (prio > vmpressure_level_oom_prio) + return; + + /* OK, the prio is below the threshold, send the pre-OOM event. */ + vmpressure(memcg, vmpressure_win, 0); +} + +/* + * Memory pressure cgroup code + */ + +struct mpc_event { + struct eventfd_ctx *efd; + enum vmpressure_levels level; + struct list_head node; +}; + +struct mpc_shrinker { + struct eventfd_ctx *efd; + size_t chunks; + size_t chunk_sz; + struct list_head node; +}; + +struct mpc_state { + struct cgroup_subsys_state css; + + uint scanned; + uint reclaimed; + struct mutex sr_lock; + + struct list_head events; + struct mutex events_lock; + + struct list_head shrinkers; + struct mutex shrinkers_lock; + + struct work_struct work; +}; + +static struct mpc_state *wk2mpc(struct work_struct *wk) +{ + return container_of(wk, struct mpc_state, work); +} + +static struct mpc_state *css2mpc(struct cgroup_subsys_state *css) +{ + return container_of(css, struct mpc_state, css); +} + +static struct mpc_state *tsk2mpc(struct task_struct *tsk) +{ + return css2mpc(task_subsys_state(tsk, mpc_cgroup_subsys_id)); +} + +static struct mpc_state *cg2mpc(struct cgroup *cg) +{ + return css2mpc(cgroup_subsys_state(cg, mpc_cgroup_subsys_id)); +} + +static void mpc_shrinker(struct mpc_state *mpc, ulong s, ulong r) +{ + struct mpc_shrinker *sh; + ssize_t to_reclaim_pages = s - r; + + if (!to_reclaim_pages) + return; + + mutex_lock(&mpc->shrinkers_lock); + + /* + * To make accounting more precise and to avoid excessive + * communication with the kernel, we operate on chunks instead of + * bytes. Say, asking to free 8 KBs makes little sense if + * granularity of allocations is 10 MBs. Also, knowing the + * granularity (chunk size) and the number of reclaimable chunks, + * we just ask that N chunks should be freed, and we assume that + * it will be freed, thus we decrement our internal counter + * straight away (i.e. userland does not need to respond how much + * was reclaimed). But, if userland could not free it, it is + * responsible to increment the counter back. + */ + list_for_each_entry(sh, &mpc->shrinkers, node) { + size_t to_reclaim_chunks; + + if (!sh->chunks) + continue; + + to_reclaim_chunks = to_reclaim_pages * + PAGE_SIZE / sh->chunk_sz; + to_reclaim_chunks = min(sh->chunks, to_reclaim_chunks); + + if (!to_reclaim_chunks) + continue; + + sh->chunks -= to_reclaim_chunks; + + eventfd_signal(sh->efd, to_reclaim_chunks); + + to_reclaim_pages -= to_reclaim_chunks * + sh->chunk_sz / PAGE_SIZE; + if (to_reclaim_pages <= 0) + break; + } + + mutex_unlock(&mpc->shrinkers_lock); +} + +static void mpc_event(struct mpc_state *mpc, ulong s, ulong r) +{ + struct mpc_event *ev; + int level = vmpressure_calc_level(vmpressure_win, s, r); + + mutex_lock(&mpc->events_lock); + + list_for_each_entry(ev, &mpc->events, node) { + if (level >= ev->level) + eventfd_signal(ev->efd, 1); + } + + mutex_unlock(&mpc->events_lock); +} + +static void mpc_vmpressure_wk_fn(struct work_struct *wk) +{ + struct mpc_state *mpc = wk2mpc(wk); + ulong s; + ulong r; + + mutex_lock(&mpc->sr_lock); + s = mpc->scanned; + r = mpc->reclaimed; + mpc->scanned = 0; + mpc->reclaimed = 0; + mutex_unlock(&mpc->sr_lock); + + mpc_shrinker(mpc, s, r); + mpc_event(mpc, s, r); +} + +static void __mpc_vmpressure(struct mpc_state *mpc, ulong s, ulong r) +{ + mutex_lock(&mpc->sr_lock); + mpc->scanned += s; + mpc->reclaimed += r; + mutex_unlock(&mpc->sr_lock); + + if (s < vmpressure_win || work_pending(&mpc->work)) + return; + + schedule_work(&mpc->work); +} + +static void mpc_vmpressure(struct mem_cgroup *memcg, ulong s, ulong r) +{ + /* + * There are two options for implementing cgroup pressure + * notifications: + * + * - Store pressure counter atomically in the task struct. Upon + * hitting 'window' wake up a workqueue that will walk every + * task and sum per-thread pressure into cgroup pressure (to + * which the task belongs). The cons are obvious: bloats task + * struct, have to walk all processes and makes pressue less + * accurate (the window becomes per-thread); + * + * - Store pressure counters in per-cgroup state. This is easy and + * straightforward, and that's how we do things here. But this + * requires us to not put the vmpressure hooks into hotpath, + * since we have to grab some locks. + */ + +#ifdef CONFIG_MEMCG + if (memcg) { + struct cgroup_subsys_state *css = mem_cgroup_css(memcg); + struct cgroup *cg = css->cgroup; + struct mpc_state *mpc = cg2mpc(cg); + + if (mpc) + __mpc_vmpressure(mpc, s, r); + return; + } +#endif + task_lock(current); + __mpc_vmpressure(tsk2mpc(current), s, r); + task_unlock(current); +} + +static struct cgroup_subsys_state *mpc_create(struct cgroup *cg) +{ + struct mpc_state *mpc; + + mpc = kzalloc(sizeof(*mpc), GFP_KERNEL); + if (!mpc) + return ERR_PTR(-ENOMEM); + + mutex_init(&mpc->sr_lock); + mutex_init(&mpc->events_lock); + mutex_init(&mpc->shrinkers_lock); + INIT_LIST_HEAD(&mpc->events); + INIT_LIST_HEAD(&mpc->shrinkers); + INIT_WORK(&mpc->work, mpc_vmpressure_wk_fn); + + return &mpc->css; +} + +static void mpc_destroy(struct cgroup *cg) +{ + struct mpc_state *mpc = cg2mpc(cg); + + kfree(mpc); +} + +static ssize_t mpc_read_level(struct cgroup *cg, struct cftype *cft, + struct file *file, char __user *buf, + size_t sz, loff_t *ppos) +{ + struct mpc_state *mpc = cg2mpc(cg); + uint level; + const char *str; + + mutex_lock(&mpc->sr_lock); + + level = vmpressure_calc_level(vmpressure_win, + mpc->scanned, mpc->reclaimed); + + mutex_unlock(&mpc->sr_lock); + + str = vmpressure_str_levels[level]; + return simple_read_from_buffer(buf, sz, ppos, str, strlen(str)); +} + +static int mpc_register_level_event(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd, + const char *args) +{ + struct mpc_state *mpc = cg2mpc(cg); + struct mpc_event *ev; + int lvl; + + for (lvl = 0; lvl < VMPRESSURE_NUM_LEVELS; lvl++) { + if (!strcmp(vmpressure_str_levels[lvl], args)) + break; + } + + if (lvl >= VMPRESSURE_NUM_LEVELS) + return -EINVAL; + + ev = kzalloc(sizeof(*ev), GFP_KERNEL); + if (!ev) + return -ENOMEM; + + ev->efd = eventfd; + ev->level = lvl; + + mutex_lock(&mpc->events_lock); + list_add(&ev->node, &mpc->events); + mutex_unlock(&mpc->events_lock); + + return 0; +} + +static void mpc_unregister_event(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd) +{ + struct mpc_state *mpc = cg2mpc(cg); + struct mpc_event *ev; + + mutex_lock(&mpc->events_lock); + list_for_each_entry(ev, &mpc->events, node) { + if (ev->efd != eventfd) + continue; + list_del(&ev->node); + kfree(ev); + break; + } + mutex_unlock(&mpc->events_lock); +} + +static int mpc_register_shrinker(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd, + const char *args) +{ + struct mpc_state *mpc = cg2mpc(cg); + struct mpc_shrinker *sh; + ulong chunk_sz; + int ret; + + ret = kstrtoul(args, 10, &chunk_sz); + if (ret) + return ret; + + sh = kzalloc(sizeof(*sh), GFP_KERNEL); + if (!sh) + return -ENOMEM; + + sh->efd = eventfd; + sh->chunk_sz = chunk_sz; + + mutex_lock(&mpc->shrinkers_lock); + list_add(&sh->node, &mpc->shrinkers); + mutex_unlock(&mpc->shrinkers_lock); + + return 0; +} + +static void mpc_unregister_shrinker(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd) +{ + struct mpc_state *mpc = cg2mpc(cg); + struct mpc_shrinker *sh; + + mutex_lock(&mpc->shrinkers_lock); + list_for_each_entry(sh, &mpc->shrinkers, node) { + if (sh->efd != eventfd) + continue; + list_del(&sh->node); + kfree(sh); + break; + } + mutex_unlock(&mpc->shrinkers_lock); +} + +static int mpc_write_shrinker(struct cgroup *cg, struct cftype *cft, + const char *str) +{ + struct mpc_state *mpc = cg2mpc(cg); + struct mpc_shrinker *sh; + struct eventfd_ctx *eventfd; + struct file *file; + ssize_t chunks; + int fd; + int ret; + + ret = sscanf(str, "%d %zd\n", &fd, &chunks); + if (ret != 2) + return -EINVAL; + + file = fget(fd); + if (!file) + return -EBADF; + + eventfd = eventfd_ctx_fileget(file); + + mutex_lock(&mpc->shrinkers_lock); + + /* Can avoid the loop once we introduce ->priv for eventfd_ctx. */ + list_for_each_entry(sh, &mpc->shrinkers, node) { + if (sh->efd != eventfd) + continue; + if (chunks < 0 && abs(chunks) > sh->chunks) + sh->chunks = 0; + else + sh->chunks += chunks; + break; + } + + mutex_unlock(&mpc->shrinkers_lock); + + eventfd_ctx_put(eventfd); + fput(file); + + return 0; +} + +static struct cftype mpc_files[] = { + { + .name = "level", + .read = mpc_read_level, + .register_event = mpc_register_level_event, + .unregister_event = mpc_unregister_event, + }, + { + .name = "shrinker", + .register_event = mpc_register_shrinker, + .unregister_event = mpc_unregister_shrinker, + .write_string = mpc_write_shrinker, + }, + {}, +}; + +struct cgroup_subsys mpc_cgroup_subsys = { + .name = "mempressure", + .subsys_id = mpc_cgroup_subsys_id, + .create = mpc_create, + .destroy = mpc_destroy, + .base_cftypes = mpc_files, +}; diff --git a/mm/vmscan.c b/mm/vmscan.c index 48550c6..d8ff846 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1877,6 +1877,9 @@ restart: shrink_active_list(SWAP_CLUSTER_MAX, lruvec, sc, LRU_ACTIVE_ANON); + vmpressure(sc->target_mem_cgroup, + sc->nr_scanned - nr_scanned, nr_reclaimed); + /* reclaim/compaction might need reclaim to continue */ if (should_continue_reclaim(lruvec, nr_reclaimed, sc->nr_scanned - nr_scanned, sc)) @@ -2099,6 +2102,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, count_vm_event(ALLOCSTALL); do { + vmpressure_prio(sc->target_mem_cgroup, sc->priority); sc->nr_scanned = 0; aborted_reclaim = shrink_zones(zonelist, sc); -- 1.8.0

13 years

3
5
0 0

(Dong Aisheng) 2012-11-04 - 2012-12-09

by Dong Aisheng

=== Highlights === * KVM/ARM VGIC state saving and restoring implementation. Did some discussion with Perter Maydell about the implementation and some various issues. Decided to try ONE_REG interface first based on his suggestion. Referred to Cache simulation code according to Perter's suggestion for banked register solution. Still digging whether it's safe to not save some gic virtual interface control registers since we do not want user level to know virtualization accel hw features in under layer . * Prepared an IMX6 flexcan support patch series. === Issues === * Have to take about two days leave(maybe more) in the coming days this week to with my family to go to hospital

13 years

1
0
0 0

[ACTIVITY] (Linus Walleij) 2012-12-03 - 2012-12-10

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Hardening and lining up pinctrl patches for the next merge window. * Spent most of the week helping others: * Reviewed a patch set for device tree support on the Nomadik pinctrl driver. * Internal pinctrl workshop. * Discussed FOSS strategies. * Discussed CodeAurora's CoreSight patches. * People at my desk 24/7 asking questions. === Plans === * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Look into regmap. Try something out, get to know it. === Issues === * Had to take a day off to watch over my daughter. * Had to put time aside for internal career development. Thanks, Linus Walleij

13 years

1
0
0 0

[ACTIVITY] (Rajanikanth H V) 2012-12-03 to 2012-12-07

by Rajanikanth HV

==== Activity Summary ==== * Implemented review comments from LeeJones on ab8500-DT delta patch set, communicated to anton. * Review discussion with deepak on runtime size gathering and updated my blueprints accordingly. * Discussion with arnd on my observation regarding drivers having FDT and "not supporting for module build", arnd is OK to have it as built-in. We can continue to measure for rest of the modules. * Did platform setup, Qemu-vexpress-a9 setup with confined/minimal rootfs to gather runtime information, first cut memory information is available from a sample ethernet module, communicated the data to arnd and others * Pinged shawn Guo to initiate run time data gathering on i.MX platform ==== Plan ==== * Work on runtime on zImage size analysis across U8500, OMAP, VExpress and i.MX ==== Issues ==== -- NA --

13 years

1
0
0 0

[ACTIVITY] (John Stultz) Dec 3-7

by John Stultz

=== Highlights === * Got the Linaro Android kernel branch updated with Anton's 3.7 forward port along with numerous updates from the AOSP 3.4 tree. * Finally merged fixes from Tixy and Tushar into Linaro-Android (sorry for being so slow!) * Discussions with Zach/Deepak around aligning Android Upstreaming team with other work being done. * Continued discussions around Minchan's vma/madvise approach to volatile ranges. * Discussed some issues with Anton around his vmpressure notification work. === Plans === * Again: Continue hacking on the vma/madvise approach to volatile ranges. - Integrate this approach into the ashmem driver - Try to add limits so it returns -EINVAL on non-tmpfs filesystems - Find a way to deal with aging anonymous pages so we purge volatile ranges in the swapoff case === Issues === * NA

13 years

1
0
0 0

RE: ACPI 5.0 implementation for armv7 and armv8 architecture

by Ayan Halder

Hi Leif/Linaro Team, Thanks for your response. >Will they both be needing ACPI? >Cortex-A5 is an ARMv7 processor. Yes I need to implement ACPI 5.0 for both( armv7 and armv8 architecture ) processors. >As I see it, C0 and C1 are straightforward enough: C0 is "running" >and C1 is corresponding to simply executing WFI/WFE without any further use of power management hardware support. To reach C2 and C3, interaction with a power controller will be necessary. The same is true for >S1-S5. Does Arm have a power controller which can fulfill such requirements. >ARM has started to work on interfaces to enable the use of generic software in power management solutions. One example of this of the Power State Coordination Interface document: >http://infocenter.arm.com/help/topic/com.arm.doc.den0022a/index.html As the document has discussed Operating System and Power Management(OSPM) and its interfaces, does ARM have any codebase which implements the features described in the document. > Some work on ACPI for ARM is being planned by the Linaro Enterprise Group. I would interested to know further the implementation of ACPI for ARM. Which ACPI model(Reduced/Fixed/Generic as described by Hardware specifications of ACPI5.0) does the Linaro group plan to implement on the SOC. Do they intend to target both armv7 and armv8 architecture? Besides adding ACPI registers and an ACPI compliant BIOS(UEFI containing ACPI tables), are there any changes from the hardware perspective( of armv7 and armv8 ). I would greatly appreciate if you could provide me some more details on this. Regards, Ayan Kumar Halder -----Original Message----- From: Leif Lindholm [mailto:leif.lindholm@linaro.org] Sent: Monday, December 03, 2012 11:49 PM To: Ayan Halder Cc: linaro-kernel(a)lists.linaro.org Subject: Re: ACPI 5.0 implementation for armv7 and armv8 archoitecture Hi, > I am planning to implement ACPI5.0 on an SOC having Cortex A5 and > Atlas cpu( based on armv8 architecture) running linux on top of them. Will they both be needing ACPI? Cortex-A5 is an ARMv7 processor. > As per the ACPI 5.0 hardware specification(Fixed Hardware/ Generic > Hardware model) of ACPI5.0, the processor needs to support various > low power modes(C0, C1, C2, C3) and sleep states(S1, S2, S3, S4, S5) > via register interfaces as well as OEM provided AML(ACPI Machine > Language). OK. > Therefore, which instructions in armv7 and armv8 put the processor > into the afore-mentioned low power modes and sleep states? > ( The arm instruction manual specifies "wfe" and "wfi" to put the > processor in a sleep state, but I am not sure if this confirms to the > ACPI 5.0 requirements ) As I see it, C0 and C1 are straightforward enough: C0 is "running" and C1 is corresponding to simply executing WFI/WFE without any further use of power management hardware support. To reach C2 and C3, interaction with a power controller will be necessary. The same is true for S1-S5. ARM has started to work on interfaces to enable the use of generic software in power management solutions. One example of this of the Power State Coordination Interface document: http://infocenter.arm.com/help/topic/com.arm.doc.den0022a/index.html (free registration required). It does not however contain ACPI-specific information. > Besides, does arm provide any AML(ACPI Machine Language) code to put > the processor to low power modes? If not, then how do we create an > ACPI machine language code for armv7 and armv8 architecture and do we > have an AML interpreter for armv7 and armv8 architecture? Not as far as I'm aware. Some work on ACPI for ARM is being planned by the Linaro Enterprise Group. / Leif

13 years

1
0
0 0

[PATCH resend 0/4] ARM: KDB FIQ debugger

by Anton Vorontsov

Hello Andrew, Russell, The KDB/NMI core support has been merged into v3.7-rc1, so the only ARM bits are pending now. I addressed all the comments ~two month ago, and since then just resending these patches. I know we're all busy, so no blaming. :) But then let's pass this via -mm? Short description of the KDB/FIQ debugger: The FIQ debugger is a facility that can be used to debug situations when the kernel stuck in uninterruptable sections, e.g. the kernel infinitely loops or deadlocked in an interrupt or with interrupts disabled. On some development boards there is even a special NMI button, which is very useful for debugging weird kernel hangs. And FIQ is basically an NMI, it has a higher priority than IRQs, and upon IRQ exception FIQs are not disabled. It is still possible to disable FIQs (as well as some "NMIs" on other architectures), but via special means. Old changelogs and a full rationale for these patches can be found here: v1-v5, rationale: http://lkml.org/lkml/2012/9/10/2 v6: http://lkml.org/lkml/2012/9/10/2 v7: http://lkml.org/lkml/2012/9/13/367 v8: http://lkml.org/lkml/2012/9/19/525 v9: http://lkml.org/lkml/2012/9/24/538 Thanks! Anton. -- arch/arm/Kconfig | 19 ++++ arch/arm/common/vic.c | 28 +++++ arch/arm/include/asm/hardware/vic.h | 2 + arch/arm/include/asm/kgdb.h | 8 ++ arch/arm/kernel/Makefile | 1 + arch/arm/kernel/entry-armv.S | 167 +-------------------------- arch/arm/kernel/entry-header.S | 170 ++++++++++++++++++++++++++++ arch/arm/kernel/kgdb_fiq.c | 124 ++++++++++++++++++++ arch/arm/kernel/kgdb_fiq_entry.S | 87 ++++++++++++++ arch/arm/mach-versatile/Makefile | 1 + arch/arm/mach-versatile/kgdb_fiq.c | 31 +++++ 11 files changed, 472 insertions(+), 166 deletions(-)

13 years

2
10
0 0

PMU Based Cycle Count Enablement

by Eric Van Hensbergen

Hi, I'm doing a bunch of high-performance computing benchmarking on ARM -- the benchmarks and runtimes like to have a fine-grained cycle counter that is available from user space (something like MFTB on PowerPC), so I've been using the PMU cycle counter in a similar fashion to what has been documented here: https://groups.google.com/forum/?fromgroups=#!topic/beagleboard/4VUJyOJx2r8 The downside is that I have to have a kernel module which enables it's use by user space, which complicates up-streaming ARM versions of the various benchmarks (as I don't want to have to include a kernel module with them....). It would seem to me that it would be better to have a sysfs interface (or something similar) which allowed privileged users to enable/disable user-land access to the PMU in the mainstream kernel. This could also help with arbitrating access to PMU from conflicting sources (such as trying to use the CCNT from user-space when it is being used by oprofile). I'm open to other suggestions, but if this sounds like a good idea I'd be willing to draft a patch to add such an interface (assuming it doesn't already exist elsewhere and I just didn't find it with some quick greps). Thanks, -eric

13 years

1
0
0 0

Arndale board Linaro kernel

by Simon Baines

Hi everyone, I'm trying to use the Linaro kernel for Ubuntu on the Arndale board as described here: https://wiki.linaro.org/Boards/Arndale/Setup/EnterpriseUbuntuServer Can anyone give advice on support for the Arndale touchscreen display board in that kernel base? Is it supported, or does the kernel not have graphics support for the board? I have tried to boot that kernel and it works so that I get a root shell on the serial port, but I'm now wanting to use the touchscreen as well but couldn't find support for it in that Linaro kernel. Can anyone confirm this? Thanks for any pointers, Simon

13 years

2
1
0 0

Performance counter's value is 0,why?

by Peng Fan

hardware platform :* Pandaboard ES Rev B1.* Processor: *Omap4460*. software Version :* linaro-12.10* kernel config: android_omap4_defconfig. I changed a few options in order to use perf. *CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_EVENTS=y CONFIG_PERF_COUNTERS=y CONFIG_HW_PERF_EVENTS=y* The command `Perf stat echo "linaro"` gives such results. root@android:/ # perf stat echo "linaro" linaro Performance counter stats for 'echo linaro': 269.561767 task-clock # 0.148 CPUs utilized 10 context-switches # 0.000 M/sec 1 CPU-migrations # 0.000 M/sec 105 page-faults # 0.000 M/sec 29678044 cycles # 0.110 GHz 0 stalled-cycles-frontend # 0.00% frontend cycles idle 0 stalled-cycles-backend # 0.00% backend cycles idle 0 instructions # 0.00 insns per cycle 0 branches # 0.000 M/sec 0 branch-misses # 0.00% of all branches 1.823486284 seconds time elapsed I use the option `-v`, and I can see that the first number of branches, instructions branch-misses and so on is zero.why? root@android:/ # perf stat -v echo "linaro" linaro task-clock: 93902590 93902590 93902590 context-switches: 9 93902590 93902590 CPU-migrations: 0 93902590 93902590 page-faults: 104 93902590 93902590 cycles: 4284725 76202392 76202392 stalled-cycles-frontend: 0 76202392 76202392 stalled-cycles-backend: 0 76202392 76202392 instructions: 0 76202392 76202392 branches: 0 76202392 76202392 branch-misses: 0 76202392 76202392 Performance counter stats for 'echo linaro': 93.902590 task-clock # 0.282 CPUs utilized 9 context-switches # 0.000 M/sec 0 CPU-migrations # 0.000 M/sec 104 page-faults # 0.001 M/sec 4284725 cycles # 0.046 GHz * 0 stalled-cycles-frontend # 0.00% frontend cycles idle 0 stalled-cycles-backend # 0.00% backend cycles idle 0 instructions # 0.00 insns per cycle 0 branches # 0.000 M/sec 0 branch-misses # 0.00% of all branches * 0.332550049 seconds time elapsed Can anybody give me suggestions?How can I use perf to get the value of hardware performance counter

13 years

3
5
0 0

Re: ACPI 5.0 implementation for armv7 and armv8 archoitecture

by Leif Lindholm

Hi, > I am planning to implement ACPI5.0 on an SOC having Cortex A5 and > Atlas cpu( based on armv8 architecture) running linux on top of > them. Will they both be needing ACPI? Cortex-A5 is an ARMv7 processor. > As per the ACPI 5.0 hardware specification(Fixed Hardware/ Generic > Hardware model) of ACPI5.0, the processor needs to support various > low power modes(C0, C1, C2, C3) and sleep states(S1, S2, S3, S4, S5) > via register interfaces as well as OEM provided AML(ACPI Machine > Language). OK. > Therefore, which instructions in armv7 and armv8 put the processor > into the afore-mentioned low power modes and sleep states? > ( The arm instruction manual specifies "wfe" and "wfi" to put the > processor in a sleep state, but I am not sure if this confirms to > the ACPI 5.0 requirements ) As I see it, C0 and C1 are straightforward enough: C0 is "running" and C1 is corresponding to simply executing WFI/WFE without any further use of power management hardware support. To reach C2 and C3, interaction with a power controller will be necessary. The same is true for S1-S5. ARM has started to work on interfaces to enable the use of generic software in power management solutions. One example of this of the Power State Coordination Interface document: http://infocenter.arm.com/help/topic/com.arm.doc.den0022a/index.html (free registration required). It does not however contain ACPI-specific information. > Besides, does arm provide any AML(ACPI Machine Language) code to put > the processor to low power modes? If not, then how do we create an > ACPI machine language code for armv7 and armv8 architecture and do > we have an AML interpreter for armv7 and armv8 architecture? Not as far as I'm aware. Some work on ACPI for ARM is being planned by the Linaro Enterprise Group. / Leif

13 years

1
0
0 0

[ACTIVITY] (Dong Aisheng) 2012-11-20 - 2012-12-03

by Dong Aisheng

* KVM/ARM VGIC state saving and restoring implementation. Completed the initial RFC patch and sent it out. [RFC PATCH 1/1] KVM: ARM: add vgic state save and restore support During the implementation, I met a lot issues and some of them were hard to make decision. There're two different ways to implement such function, however, each way has different issues. I currently can not make sure which one is better. So i raised them in the RFC patch and request for people's comments and suggestions.

13 years

1
0
0 0

[ACTIVITY] (Rajanikanth H V) 2012-11-26 to 2012-11-30

by Rajanikanth HV

==== Activity Summary ==== - Communicated final patch to anton regarding ab8500 BM devices which is over the - Communicated detailed observation with possible suspect on snowball ethernet issue to linus, lee. lee suggested a clk related patch(http://paste.ubuntu.com/1396710/) from linus which did not help - Discussion with arnd on Runtime size analysis, finalized steps to analyze and test, updated blueprint accordingly. - Discussion with shawnguo regarding i.MX support for runtime size information, understood that some of the drivers does not support module build, same with u8500 as well - Completed first cut Static data gathering from vmlinux across all the platforms ==== Plan ==== * Work on runtime on zImage size analysis across U8500, OMAP, VExpress and i.MX * Discuss with arnd on runtime size analysis under the case where some of the drivers does not support module build ==== Issues ==== -- NA --

13 years

1
1
0 0

ACPI 5.0 implementation for armv7 and armv8 archoitecture

by Ayan Halder

Hi, I am planning to implement ACPI5.0 on an SOC having Cortex A5 and Atlas cpu( based on armv8 architecture) running linux on top of them. As per the ACPI 5.0 hardware specification(Fixed Hardware/ Generic Hardware model) of ACPI5.0, the processor needs to support various low power modes(C0, C1, C2, C3) and sleep states(S1, S2, S3, S4, S5) via register interfaces as well as OEM provided AML(ACPI Machine Language). Therefore, which instructions in armv7 and armv8 put the processor into the afore-mentioned low power modes and sleep states? ( The arm instruction manual specifies "wfe" and "wfi" to put the processor in a sleep state, but I am not sure if this confirms to the ACPI 5.0 requirements ) Besides, does arm provide any AML(ACPI Machine Language) code to put the processor to low power modes? If not, then how do we create an ACPI machine language code for armv7 and armv8 architecture and do we have an AML interpreter for armv7 and armv8 architecture? Regards, Ayan Kumar Halder

13 years

1
0
0 0

[ACTIVITY] (Linus Walleij) 2012-11-24 - 2012-12-02

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Got sidetracked for two days by a regression in the clk subsystem for ux500 found by Lee Jones. Since I try to police this platform whenever something breaks I will be the last resort. Finally nailed and fixed the bug after first doing the completely wrong thing, resulting in a one-liner patch. No idea on how to blueprint/track such things, ideas welcome. * Hardening and lining up pinctrl patches for the next merge window. * Synchronized GPIO trees with Grant. * Reviewed a patch set of 77 patches from Laurent Pinchard moving the SH architecture over to using pin control. Did this by reviewing the end result, needless to say this took some time. * Sent Integrator pull requests to ARM SoC. === Plans === * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9. * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Look into regmap. Try something out, get to know it. === Issues === * Had to take a day off to watch over my daughter. * Had to put time aside for internal career development. Thanks, Linus Walleij

13 years

1
0
0 0

[RFC] Add mempressure cgroup

by Anton Vorontsov

This is an attempt to implement David Rientjes' idea of mempressure cgroup. The main characteristics are the same to what I've tried to add to vmevent API: Internally, it uses Mel Gorman's idea of scanned/reclaimed ratio for pressure index calculation. But we don't expose the index to the userland. Instead, there are three levels of the pressure: o low (just reclaiming, e.g. caches are draining); o medium (allocation cost becomes high, e.g. swapping); o oom (about to oom very soon). The rationale behind exposing levels and not the raw pressure index described here: http://lkml.org/lkml/2012/11/16/675 The API uses standard cgroups eventfd notifications: $ gcc Documentation/cgroups/cgroup_event_listener.c -o \ cgroup_event_listener $ cd /sys/fs/cgroup/ $ mkdir mempressure $ mount -t cgroup cgroup ./mempressure -o mempressure $ cd mempressure $ cgroup_event_listener ./mempressure.level low ("low", "medium", "oom" are permitted values.) Upon hitting the threshold, you should see "/sys/fs/cgroup/mempressure low: crossed" messages. To test that it actually works on per-cgroup basis, I did a small trick: I moved all kswapd into a separate cgroup, and hooked the listener onto another (non-root) cgroup. The listener no longer received global reclaim pressure, which is expected. For a task it is possible to be in both cpusets, memcg and mempressure cgroups, so by rearranging the tasks it should be possible to watch a specific pressure. Note that while this adds the cgroups support, the code is well separated and eventually we might add a lightweight, non-cgroups API, i.e. vmevent. But this is another story. Signed-off-by: Anton Vorontsov <anton.vorontsov(a)linaro.org> --- include/linux/cgroup_subsys.h | 6 + include/linux/vmstat.h | 8 ++ init/Kconfig | 5 + mm/Makefile | 1 + mm/mempressure.c | 287 ++++++++++++++++++++++++++++++++++++++++++ mm/vmscan.c | 3 + 6 files changed, 310 insertions(+) create mode 100644 mm/mempressure.c diff --git a/include/linux/cgroup_subsys.h b/include/linux/cgroup_subsys.h index f204a7a..b9802e2 100644 --- a/include/linux/cgroup_subsys.h +++ b/include/linux/cgroup_subsys.h @@ -37,6 +37,12 @@ SUBSYS(mem_cgroup) /* */ +#if IS_SUBSYS_ENABLED(CONFIG_CGROUP_MEMPRESSURE) +SUBSYS(mpc_cgroup) +#endif + +/* */ + #if IS_SUBSYS_ENABLED(CONFIG_CGROUP_DEVICE) SUBSYS(devices) #endif diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h index 92a86b2..7698341 100644 --- a/include/linux/vmstat.h +++ b/include/linux/vmstat.h @@ -10,6 +10,14 @@ extern int sysctl_stat_interval; +#ifdef CONFIG_CGROUP_MEMPRESSURE +extern void vmpressure(ulong scanned, ulong reclaimed); +extern void vmpressure_prio(int prio); +#else +static inline void vmpressure(ulong scanned, ulong reclaimed) {} +static inline void vmpressure_prio(int prio) {} +#endif + #ifdef CONFIG_VM_EVENT_COUNTERS /* * Light weight per cpu counter implementation. diff --git a/init/Kconfig b/init/Kconfig index 6fdd6e3..7065e44 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -826,6 +826,11 @@ config MEMCG_KMEM the kmem extension can use it to guarantee that no group of processes will ever exhaust kernel resources alone. +config CGROUP_MEMPRESSURE + bool "Memory pressure monitor for Control Groups" + help + TODO + config CGROUP_HUGETLB bool "HugeTLB Resource Controller for Control Groups" depends on RESOURCE_COUNTERS && HUGETLB_PAGE && EXPERIMENTAL diff --git a/mm/Makefile b/mm/Makefile index 6b025f8..40cee19 100644 --- a/mm/Makefile +++ b/mm/Makefile @@ -50,6 +50,7 @@ obj-$(CONFIG_MIGRATION) += migrate.o obj-$(CONFIG_QUICKLIST) += quicklist.o obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o obj-$(CONFIG_MEMCG) += memcontrol.o page_cgroup.o +obj-$(CONFIG_CGROUP_MEMPRESSURE) += mempressure.o obj-$(CONFIG_CGROUP_HUGETLB) += hugetlb_cgroup.o obj-$(CONFIG_MEMORY_FAILURE) += memory-failure.o obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o diff --git a/mm/mempressure.c b/mm/mempressure.c new file mode 100644 index 0000000..5c85bbe --- /dev/null +++ b/mm/mempressure.c @@ -0,0 +1,287 @@ +/* + * Linux VM pressure notifications + * + * Copyright 2012 Linaro Ltd. + * Anton Vorontsov <anton.vorontsov(a)linaro.org> + * + * Based on ideas from David Rientjes, KOSAKI Motohiro, Leonid Moiseichuk, + * Mel Gorman, Minchan Kim and Pekka Enberg. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include <linux/cgroup.h> +#include <linux/fs.h> +#include <linux/sched.h> +#include <linux/mm.h> +#include <linux/vmstat.h> +#include <linux/atomic.h> +#include <linux/eventfd.h> +#include <linux/swap.h> +#include <linux/printk.h> + +static void mpc_vmpressure(ulong scanned, ulong reclaimed); + +/* + * Generic VM Pressure routines (no cgroups or any other API details) + */ + +/* These are defaults. Might make them configurable one day. */ +static const uint vmpressure_win = SWAP_CLUSTER_MAX * 16; +static const uint vmpressure_level_med = 60; +static const uint vmpressure_level_oom = 99; +static const uint vmpressure_level_oom_prio = 4; + +enum vmpressure_levels { + VMPRESSURE_LOW = 0, + VMPRESSURE_MEDIUM, + VMPRESSURE_OOM, + VMPRESSURE_NUM_LEVELS, +}; + +static const char const *vmpressure_str_levels[] = { + [VMPRESSURE_LOW] = "low", + [VMPRESSURE_MEDIUM] = "medium", + [VMPRESSURE_OOM] = "oom", +}; + +static enum vmpressure_levels vmpressure_level(uint pressure) +{ + if (pressure >= vmpressure_level_oom) + return VMPRESSURE_OOM; + else if (pressure >= vmpressure_level_med) + return VMPRESSURE_MEDIUM; + return VMPRESSURE_LOW; +} + +static ulong vmpressure_calc_level(uint win, uint s, uint r) +{ + ulong p; + + if (!s) + return 0; + + /* + * We calculate the ratio (in percents) of how many pages were + * scanned vs. reclaimed in a given time frame (window). Note that + * time is in VM reclaimer's "ticks", i.e. number of pages + * scanned. This makes it possible to set desired reaction time + * and serves as a ratelimit. + */ + p = win - (r * win / s); + p = p * 100 / win; + + pr_debug("%s: %3lu (s: %6u r: %6u)\n", __func__, p, s, r); + + return vmpressure_level(p); +} + +void vmpressure(ulong scanned, ulong reclaimed) +{ + if (!scanned) + return; + mpc_vmpressure(scanned, reclaimed); +} + +void vmpressure_prio(int prio) +{ + if (prio > vmpressure_level_oom_prio) + return; + + /* OK, the prio is below the threshold, send the pre-OOM event. */ + vmpressure(vmpressure_win, 0); +} + +/* + * Memory pressure cgroup code + */ + +struct mpc_state { + struct cgroup_subsys_state css; + uint scanned; + uint reclaimed; + struct mutex lock; + struct eventfd_ctx *eventfd; + enum vmpressure_levels thres; +}; + +static struct mpc_state *css2mpc(struct cgroup_subsys_state *css) +{ + return container_of(css, struct mpc_state, css); +} + +static struct mpc_state *tsk2mpc(struct task_struct *tsk) +{ + return css2mpc(task_subsys_state(tsk, mpc_cgroup_subsys_id)); +} + +static struct mpc_state *cg2mpc(struct cgroup *cg) +{ + return css2mpc(cgroup_subsys_state(cg, mpc_cgroup_subsys_id)); +} + +static void __mpc_vmpressure(ulong scanned, ulong reclaimed) +{ + struct mpc_state *mpc = tsk2mpc(current); + int level; + + mpc->scanned += scanned; + mpc->reclaimed += reclaimed; + + if (mpc->scanned < vmpressure_win) + return; + + level = vmpressure_calc_level(vmpressure_win, + mpc->scanned, mpc->reclaimed); + if (level >= mpc->thres) { + mutex_lock(&mpc->lock); + if (mpc->eventfd) + eventfd_signal(mpc->eventfd, 1); + mutex_unlock(&mpc->lock); + } +} + +static void mpc_vmpressure(ulong scanned, ulong reclaimed) +{ + /* + * There are two options for implementing cgroup pressure + * notifications: + * + * - Store pressure counter atomically in the task struct. Upon + * hitting 'window' wake up a workqueue that will walk every + * task and sum per-thread pressure into cgroup pressure (to + * which the task belongs). The cons are obvious: bloats task + * struct, have to walk all processes and makes pressue less + * accurate (the window becomes per-thread); + * + * - Store pressure counters in per-cgroup state. This is easy and + * straighforward, and that's how we do things here. But this + * requires us to not put the vmpressure hooks into hotpath, + * since we have to grab some locks. + */ + task_lock(current); + __mpc_vmpressure(scanned, reclaimed); + task_unlock(current); +} + +static struct cgroup_subsys_state *mpc_create(struct cgroup *cg) +{ + struct mpc_state *mpc; + + mpc = kzalloc(sizeof(*mpc), GFP_KERNEL); + if (!mpc) + return ERR_PTR(-ENOMEM); + + mutex_init(&mpc->lock); + + return &mpc->css; +} + +static int mpc_pre_destroy(struct cgroup *cg) +{ + struct mpc_state *mpc = cg2mpc(cg); + int ret = 0; + + mutex_lock(&mpc->lock); + + if (mpc->eventfd) + ret = -EBUSY; + + mutex_unlock(&mpc->lock); + + return ret; +} + +static void mpc_destroy(struct cgroup *cg) +{ + struct mpc_state *mpc = cg2mpc(cg); + + kfree(mpc); +} + +static ssize_t mpc_read_level(struct cgroup *cg, struct cftype *cft, + struct file *file, char __user *buf, + size_t sz, loff_t *ppos) +{ + struct mpc_state *mpc = cg2mpc(cg); + uint level; + const char *str; + + mutex_lock(&mpc->lock); + + level = vmpressure_calc_level(vmpressure_win, + mpc->scanned, mpc->reclaimed); + mpc->scanned = 0; + mpc->reclaimed = 0; + + mutex_unlock(&mpc->lock); + + str = vmpressure_str_levels[level]; + return simple_read_from_buffer(buf, sz, ppos, str, strlen(str)); +} + +static int mpc_register_level_event(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd, + const char *args) +{ + struct mpc_state *mpc = cg2mpc(cg); + int i; + int ret; + + mutex_lock(&mpc->lock); + + /* + * It's easy to implement multiple thresholds, but so far we don't + * need it. + */ + if (mpc->eventfd) { + ret = -EBUSY; + goto out_unlock; + } + + ret = -EINVAL; + for (i = 0; i < VMPRESSURE_NUM_LEVELS; i++) { + if (strcmp(vmpressure_str_levels[i], args)) + continue; + mpc->eventfd = eventfd; + mpc->thres = i; + ret = 0; + break; + } +out_unlock: + mutex_unlock(&mpc->lock); + + return ret; +} + +static void mpc_unregister_level_event(struct cgroup *cg, struct cftype *cft, + struct eventfd_ctx *eventfd) +{ + struct mpc_state *mpc = cg2mpc(cg); + + mutex_lock(&mpc->lock); + BUG_ON(mpc->eventfd != eventfd); + mpc->eventfd = NULL; + mutex_unlock(&mpc->lock); +} + +static struct cftype mpc_files[] = { + { + .name = "level", + .read = mpc_read_level, + .register_event = mpc_register_level_event, + .unregister_event = mpc_unregister_level_event, + }, + {}, +}; + +struct cgroup_subsys mpc_cgroup_subsys = { + .name = "mempressure", + .subsys_id = mpc_cgroup_subsys_id, + .create = mpc_create, + .pre_destroy = mpc_pre_destroy, + .destroy = mpc_destroy, + .base_cftypes = mpc_files, +}; diff --git a/mm/vmscan.c b/mm/vmscan.c index 48550c6..430d8a5 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1877,6 +1877,8 @@ restart: shrink_active_list(SWAP_CLUSTER_MAX, lruvec, sc, LRU_ACTIVE_ANON); + vmpressure(sc->nr_scanned - nr_scanned, nr_reclaimed); + /* reclaim/compaction might need reclaim to continue */ if (should_continue_reclaim(lruvec, nr_reclaimed, sc->nr_scanned - nr_scanned, sc)) @@ -2099,6 +2101,7 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist, count_vm_event(ALLOCSTALL); do { + vmpressure_prio(sc->priority); sc->nr_scanned = 0; aborted_reclaim = shrink_zones(zonelist, sc); -- 1.8.0

13 years

5
10
0 0

[ACTIVITY] (John Stultz) Nov 26-30

by John Stultz

=== Highlights === * Continued playing with and hacking on Minchan's vma based anonymous volatile range patch * Lots of reading of the madvise/mmap/rmap code * Found a few bugs with Minchan's approach and resolved them * Got Minchan's approach working w/ files, so it can be used on tmpfs * Sent out my git tree of changes for review to lkml * Sent out weekly upstreaming status mail * Reviewed a merge_config.sh patch * Replied to some mails about perf timestamps and ntp behavior === Plans === * Continue hacking on the vma/madvise approach to volatile ranges. - Try to add limits so it returns -EINVAL on non-tmpfs filesystems - Find a way to deal with aging anonymous pages so we purge volatile ranges in the swapoff case - Integrate this approach into the ashmem driver * Re-merge Anton's 3.7 forward port of the android patchset into my linaro-android tree - Add fixes from Tixy and others that are pending - Possibly re-update the tree from the 3.4 branch * Bunch of other community issues to look at again === Issues === * NA

13 years

1
0
0 0

[ACTIVITY] (Appala) 2012-11-26 to 2012-11-30

by Appala Bade

==== Activity Summary ==== 1.Analyzed Binder IPC driver and Middleware source code. 2.Drafted binder unit testcase to implement( https://docs.google.com/a/linaro.org/document/d/1uqjaK4eEyjBgT7-p3tSK0zZIg-… ). 3.Working on Juice project environment setup. Thanks, Appala

13 years

1
0
0 0

omap4iss driver code missing in Linaro 12.07

by S.Sharavana Ram Kumar

Hi, I have the source code of Linaro ICS kernel 3.4 (Linaro version 12.07). In this kernel source code V4L2 driver related to omap4 Camera (omap4 iss) is missing. In the earlier ICS kernel 3.2, it was under the folder drivers/media/video/omap4iss Is it replaced with some other driver or should I take it from to previous ICS kernel 3.2 version? Please provide some pointers related to this. ----- Regards, S.Sharavana

13 years

2
1
0 0

[PATCH] ARM: mm: Allow an empty PMD in alloc_init_pte()

by Jon Medhurst (Tixy)

The Android patch titled "ARM: allow the kernel text section to be made read-only" modifies alloc_init_pte() and adds a BUG_ON to detect the case where a section mapping is being overwritten. However the test doesn't allow for the legitimate case where the PMD is empty, as can happen for kernels built with CONFIG_ARM_LPAE. So extend the test to allow this. Signed-off-by: Jon Medhurst <tixy(a)linaro.org> --- arch/arm/mm/mmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c index 9eb7a4e..c35bbda 100644 --- a/arch/arm/mm/mmu.c +++ b/arch/arm/mm/mmu.c @@ -587,7 +587,7 @@ static void __init alloc_init_pte(pmd_t *pmd, unsigned long addr, pte_t *pte = start_pte + pte_index(addr); /* If replacing a section mapping, the whole section must be replaced */ - BUG_ON(pmd_bad(*pmd) && ((addr | end) & ~PMD_MASK)); + BUG_ON(!pmd_none(*pmd) && pmd_bad(*pmd) && ((addr | end) & ~PMD_MASK)); do { set_pte_ext(pte, pfn_pte(pfn, __pgprot(type->prot_pte)), 0); -- 1.7.10.4

13 years

1
0
0 0

[RFC PATCH] ARM: ftrace: Ensure code modifications are synchronised across all cpus

by Jon Medhurst (Tixy)

When the generic ftrace implementation modifies code for trace-points it uses stop_machine() to call ftrace_modify_all_code() on one CPU. This ultimately calls the ARM specific function ftrace_modify_code() which updates the instruction and then does flush_icache_range(). As this cache flushing only operates on the local CPU then other cores may end up execute the old instruction if it's still in their icaches. This may or may not cause problems for the use of ftrace on kernels compiled for ARM instructions. However, Thumb2 instructions can straddle two cache lines so its possible for half the old instruction to be in the cache and half the new one, leading the the CPU executing garbage. This patch fixes this situation by providing and arch specific implementation of arch_ftrace_update_code() which ensures that after one core has modified all the code, the other cores invalidate their icaches before continuing. Signed-off-by: Jon Medhurst <tixy(a)linaro.org> --- arch/arm/kernel/ftrace.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c index 34e5664..38b670c 100644 --- a/arch/arm/kernel/ftrace.c +++ b/arch/arm/kernel/ftrace.c @@ -14,6 +14,7 @@ #include <linux/ftrace.h> #include <linux/uaccess.h> +#include <linux/stop_machine.h> #include <asm/cacheflush.h> #include <asm/opcodes.h> @@ -156,6 +157,39 @@ int ftrace_make_nop(struct module *mod, return ret; } +struct afmc_data { + int command; + atomic_t cpu; + atomic_t done; +}; + +static int __arch_ftrace_modify_code(void *data) +{ + struct afmc_data *afmcd = data; + + if (atomic_inc_return(&afmcd->cpu) == num_online_cpus()) { + /* Last cpu to get into this function does the actual work */ + ftrace_modify_all_code(afmcd->command); + wmb(); + atomic_set(&afmcd->done, true); + } else { + /* Other cpus wait for the code modifications to be done */ + rmb(); + while (!atomic_read(&afmcd->done)) + cpu_relax(); + /* Ensure icache is consistent with the code changes */ + __flush_icache_all(); + } + + return 0; +} + +void arch_ftrace_update_code(int command) +{ + struct afmc_data afmcd = { command }; + stop_machine(__arch_ftrace_modify_code, &afmcd, cpu_online_mask); +} + int __init ftrace_dyn_arch_init(void *data) { *(unsigned long *)data = 0; -- 1.7.10.4

13 years

1
0
0 0

[PATCH resend 0/10] Get rid of FIQ_START/enable/disable_fiq() + some FIQ cleanups

by Anton Vorontsov

Hello Andrew, Russell, These are small cleanups that I keep resending since Aug. Andrew, can you please take them for the time being? The rationale is the same: During KDB FIQ patches review Russell mentioned that I should not introduce another FIQ_START. It seems that in v3.6-rc the FIQ_START issue was somewhat band-aided, i.e. machines don't necessary need to define this stuff any longer, but I also read the background of the issue, and Russell once said that he don't want the FIQ subsystem to mess with genirq. So, the patch set is pretty straightforward: - Get rid of FIQ_START. Nobody but platform-specific code (and platform-specific drivers) should know the details about which interrupt can be routed to FIQ and which cannot; - Remove disable/enable_fiq() calls from the FIQ subsys. Thanks! -- arch/arm/include/asm/fiq.h | 2 - arch/arm/include/asm/mach/irq.h | 7 +++- arch/arm/kernel/fiq.c | 37 +++++-------------- arch/arm/kernel/irq.c | 2 - arch/arm/mach-omap1/include/mach/irqs.h | 4 -- arch/arm/mach-rpc/dma.c | 4 +- arch/arm/mach-rpc/include/mach/irqs.h | 8 ++-- arch/arm/mach-rpc/irq.c | 21 ++--------- arch/arm/mach-s3c24xx/include/mach/irqs.h | 3 -- arch/arm/plat-mxc/avic.c | 5 --- arch/arm/plat-mxc/include/mach/irqs.h | 2 - arch/arm/plat-mxc/tzic.c | 5 --- arch/arm/plat-s3c24xx/irq.c | 6 +-- .../media/platform/soc_camera/mx1_camera.c | 6 +-- sound/soc/fsl/imx-pcm-fiq.c | 4 +- 15 files changed, 31 insertions(+), 85 deletions(-)

13 years

3
17
0 0

[RFC v3 0/3] vmpressure_fd: Linux VM pressure notifications

by Anton Vorontsov

Hi all, This is the third RFC. As suggested by Minchan Kim, the API is much simplified now (comparing to vmevent_fd): - As well as Minchan, KOSAKI Motohiro didn't like the timers, so the timers are gone now; - Pekka Enberg didn't like the complex attributes matching code, and so it is no longer there; - Nobody liked the raw vmstat attributes, and so they were eliminated too. But, conceptually, it is the exactly the same approach as in v2: three discrete levels of the pressure -- low, medium and oom. The levels are based on the reclaimer inefficiency index as proposed by Mel Gorman, but userland does not see the raw index values. The description why I moved away from reporting the raw 'reclaimer inefficiency index' can be found in v2: http://lkml.org/lkml/2012/10/22/177 While the new API is very simple, it is still extensible (i.e. versioned). As there are a lot of drastic changes in the API itself, I decided to just add a new files along with vmevent, it is much easier to review it this way (I can prepare a separate patch that removes vmevent files, if we care to preserve the history through the vmevent tree). Thanks, Anton. -- Documentation/sysctl/vm.txt | 47 +++++ arch/x86/syscalls/syscall_64.tbl | 1 + include/linux/syscalls.h | 2 + include/linux/vmpressure.h | 128 ++++++++++++ kernel/sys_ni.c | 1 + kernel/sysctl.c | 31 +++ mm/Kconfig | 13 ++ mm/Makefile | 1 + mm/vmpressure.c | 231 +++++++++++++++++++++ mm/vmscan.c | 5 + tools/testing/vmpressure/.gitignore | 1 + tools/testing/vmpressure/Makefile | 30 +++ tools/testing/vmpressure/vmpressure-test.c | 93 +++++++++ 13 files changed, 584 insertions(+)

13 years

14
52
0 0

[ACTIVITY] (Rajanikanth H V) 2012-11-19 to 2012-11-23

by Rajanikanth HV

==== Activity Summary ==== - Finalized the blueprint based on detailed requirements captured Note: i.MX is the new platform added to analysis list - Collected build time kernel image and driver data size information across the required platform: - Was blocked on collecting runtime kernel and modules sizes information on u8500 platform, as i found boot time issue on 3.7-rc6 version: Ethernet driver is failing to initialize, debugging further i found that regulator for smsc911x chip is not being turned on. Note: Did not observe above said issue on 3.6, - Implemented review comments from "francesco lavra" regarding ab8500 mfd BM devices patches, manually rebased(against 3.7-rc6), tested and communicated the patchset to ML's. - Anton has merged my previous patch set(thanks to anton), preparing delta patches with the latest one ==== Plan ==== - Communicate delta patchs for ab8500 mfd to anton - Continue to gather and analyze build and runtime size information - Discuss and consolidate with arnd on the zImage size data ontained ==== Issues ==== 0.5 day holiday

13 years

1
0
0 0

[ACTIVITY] (Anton Vorontsov) 2012-11-12 - 2012-11-23

by Anton Vorontsov

== Highlights == * While cgroups discussion was ongoing, I finally found some time to revive my Android emulator setup and validate stock out of memory killer. Running with in-kernel LMK completely disabled (and using ulmkd instead) I could trigger OOMK by large instant allocations, and the OOMK was always choosing the right target (i.e. w/ the correct oom_adj). So it behaves exactly as expected, and I could not reproduce any rumoured issues with it; * Started work on mempressure cgroup and per-thread vmpressure. Basically, this is 'everything from scratch', again. :( This will surely slip v3.8, although hopefully I'll have a draft/RFC to show this week; * Resent KDB/FIQ/Kiosk patches, this time to Andrew Morton.

13 years

1
0
0 0

[ACTIVITY] (Linus Walleij) 2012-11-20 - 2012-11-23

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Intense activity on pinctrl and gpio trees, also sending yet another round of pull requests for fixes to Torvalds for GPIO. * Switched the U300 over to use the GPIO ranges. Discovered more issues with the solution and solved them with another 10 patches to the related code and drivers. https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-gpiorange-makeo… * Finalized my GPIO patch stack and sent of a pull request to Grant so he can funnel this to Torvalds for kernel v3.8. * Discussed the status of the CW1200 driver in a lot of private mails. * Acked a plethora of patches for the removal of __devinit * Send clock patches for the Integrator/IM-PD1 to Mike Turquette, he merged them. === Plans === * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9 or so. (Make no promises, make no commitments...) * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Look into regmap. Try something out, get to know it. === Issues === * The GPIO range blueprint got escalated above the single zImage work due to influx from the community. Since contribuitors drive the process this happens... It was work that was on our blueprint list, but we could not control the priority of execution. I think this is normal but it needs to be reported and noted. Thanks, Linus Walleij

13 years

1
0
0 0

[PATCH resend 0/7] KDB: Kiosk (reduced capabilities) mode

by Anton Vorontsov

Hi Andrew, Jason, And yet another set that folks seem to be too busy to look into. :) The rationale for the series is this: This patchset implements "kiosk" mode for KDB debugger. The mode reduces kdb features, so that it is no longer possible to leak sensitive data via the debugger, and not possible to change program flow in a predefined manner by an ordinary user. The root can control the capability. It is useful on phones with an easy access to a debugger console (e.g. thru a headphone mini-jack), or on a public PCs (but we still want to let the user somewhat diagnose the problem via KDB-via-KMS). Later we might want to implement password-protected "unlock" command (with the hash of the password passed via some sysfs attribute). There are a few patches, some are just cleanups, some are churn-ish cleanups, but inevitable. And the rest implements the mode -- after all the preparations, everything is pretty straightforward. Thanks! Anton. -- include/linux/kdb.h | 20 ++-- kernel/debug/kdb/kdb_bp.c | 24 ++--- kernel/debug/kdb/kdb_main.c | 189 +++++++++++++++++---------------- kernel/debug/kdb/kdb_private.h | 3 +- kernel/trace/trace_kdb.c | 4 +- 5 files changed, 125 insertions(+), 115 deletions(-)

13 years

1
7
0 0

Fwd: [ACTIVITY] (Linus Walleij) 2012-11-11 - 2012-11-19

by Linus Walleij

Items of public interest from 1:1 protocol... On Mon, Nov 19, 2012 at 9:22 PM, Deepak Saxena <dsaxena(a)linaro.org> wrote: > On 19 November 2012 02:03, Linus Walleij <linus.walleij(a)linaro.org> wrote: >> * Intense activity on pinctrl and gpio trees, also sending >> a second round of pull requests for fixes to Torvalds >> for GPIO. > > Is this work beyond what's in the two BPs below? If not, can you > create BPs for sort of random maintenance work that comes up and just > throw things on there as they come up? We're still trying to sort out > the best way to use the BPs but there's a lot of pressure to make sure > that we have good tracking of all the work we're doing. So this has basically been just collecting patches that people send on the mailing list, ask a question, git commit --amend to add an ACK, push -next branches etc to the git servers etc. It adds up. I don't know how to properly encode that into a blueprint without the detailing taking more time than the actual work, shall I create a blueprint named "pinctrl maintenance" and "gpio maintenance" and just push in weekly TODO items there with titles like "monitor mailing list", "extract patches", "apply patches", "push branches", "read Rothwells merge log", etc? >> * Sent a patch set to move the Integrators over to the SoC >> bus (Lee's invention) when booting from device tree, >> and at the same time find a natural place to define >> system controller registers. This is meant as a good >> example of how to use the SoC bus. > > -EANOTHERBUS? How does the SoC bus compare to the newly proposed > Capebus. What does it offer that is not already in the platform bus? I'm not familiar with the Capebus... This one was discussed between Lee, Greg and Arnd and they agreed that this was the way to create a container for all the peripherals on an SoC. > PPC went down the path of having an "Off-Chip Peripheral Bus" to > describe devices and then threw it all away a few years ago, so > wondering how this compares. So this is an on-chip peripheral bus. It will group typically AMBA (PrimeCell) and platform devices that sit in the same die. Check commit: 74d1d82cdaaec727f5072eb1c9f49b7e920e076f Yours, Linus Walleij

13 years

1
1
0 0

Questions For Generic Timer Frequency On Fast Model

by Leo Yan

hi all, Now when i debug the Linux kernel on Fast Model (A15x1+A7x1), i found the generic timer's frequency cannot work properly. In the boot-wrapper, it has set the frequency as 24MHz; and i also use the modeldebugger to confirm it has been set successfully. But after the linux kernel bootup, i saw the counter register increased quicker than 24MHz, so that the kernel cannot get the correct timestamp. I'm not sure it's a issue originally come from the model? Or i miss something. There have method to fix this issue? Any suggestion will be appreciate. -- Thx, Leo Yan

13 years

2
3
0 0

[ACTIVITY] (Linus Walleij) 2012-11-11 - 2012-11-19

by Linus Walleij

== Linus Walleij linusw == === Highlights === * Intense activity on pinctrl and gpio trees, also sending a second round of pull requests for fixes to Torvalds for GPIO. * Debated default-hogging of pinctrl handles. We NACKed the idea to use notifications to obtain hogs as it can't handle deferred probes properly, instead we will attempt to push this to the device driver core. https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-notifyhog * Probably finished the GPIO-range blueprint work, but need to switch the U300 over to this mechanism as a trial platform: https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-gpiorange-makeo… * Sent a patch set to move the Integrators over to the SoC bus (Lee's invention) when booting from device tree, and at the same time find a natural place to define system controller registers. This is meant as a good example of how to use the SoC bus. * Had a final look at Synaptic's RMI4 patch set, I've reviewed all that I can, now it remains for Dmitry and Greg to review the final pieces of the architecture. * Initial Integrator/IM-PD1 patches being cooked. === Plans === * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9 or so. (Make no promises, make no commitments...) * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Look into regmap. Try something out, get to know it. === Issues === * N/A Thanks, Linus Walleij

13 years

2
1
0 0

[ACTIVITY] (Dong Aisheng) 2012-11-13 - 2012-11-19

by Dong Aisheng

=== Highlights === * KVM/ARM VGIC state saving and restoring implementation. 1) read the full software emulated gic code hw/arm_gic.c to understand the original gic_state using 2) started to define the standard ABI of gic state for user space to use. The work consists of two part: kernel vgic part and user level qemu part. I would firstly complete kernel vgic part. During the process, mainly two problems met: Firstly, unlike kvm_pic_state of x86, the gic_state, mainly used by fully sw emulated gic in hw/arm_gic.c, is not used by kernel vgic code and most of its members are also not used by hw assisted hw/kvm/arm_gic.c code, i probably need define a new standard gic state structure interface in kvm_irqchip for qemu to use, may be named kvm_gic_state. Secondly, currently i only know to the test method via savevm on a single virtual machine, this is the first target. In the future, we may support multi targets. Will keep going as this and send patch first. * Reviewed a few imx pinctrl patches * Invovled with a few FSL internal meetings on the i.MX changes.

13 years

1
0
0 0

[ACTIVITY] (Rajanikanth H V) 2012-11-12 to 2012-11-16

by Rajanikanth HV

==== Activity Summary ==== - Implemented review comments from Francesco, waiting for ack. - Pinged Rob for review comments and ack - Rebasing ab8500-dt patch set to 3.7-rc5 - Discussion with Arnd on my new blueprint: "impact on kernel size for multi-platform configs" Thanks arnd for his useful inputs - Updated in my Blue Print with the detailed work items ==== Plan ==== - Rebase (manually) ab8500 DT patch and test - Review and rework on the work items details and proceed accordingly ==== Issues ==== 2 days holiday

13 years

1
0
0 0

[PATCH V6 0/2] Upstream ST-Ericsson thermal driver

by hongbo.zhang

From: "hongbo.zhang" <hongbo.zhang(a)linaro.com> V5->V6 Changes: In patch "Thermal: Add ST-Ericsson DB8500 thermal driver": - Add depends on ARCH_U8500 in Kconfig In patch "Thermal: Add ST-Ericsson DB8500 thermal properties and platform - Add Acked-by: Linus Walleij <linus.walleij(a)linaro.org> hongbo.zhang (2): Thermal: Add ST-Ericsson DB8500 thermal driver. Thermal: Add ST-Ericsson DB8500 thermal properties and platform data. .../devicetree/bindings/thermal/db8500-thermal.txt | 44 ++ arch/arm/boot/dts/dbx5x0.dtsi | 14 + arch/arm/boot/dts/snowball.dts | 31 ++ arch/arm/configs/u8500_defconfig | 2 + arch/arm/mach-ux500/board-mop500.c | 64 +++ drivers/thermal/Kconfig | 20 + drivers/thermal/Makefile | 2 + drivers/thermal/db8500_cpufreq_cooling.c | 108 +++++ drivers/thermal/db8500_thermal.c | 531 +++++++++++++++++++++ include/linux/platform_data/db8500_thermal.h | 38 ++ 10 files changed, 854 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/db8500-thermal.txt create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c create mode 100644 drivers/thermal/db8500_thermal.c create mode 100644 include/linux/platform_data/db8500_thermal.h -- 1.8.0

13 years

3
6
0 0

[ACTIVITY] (John Stultz) Nov 12-16th

by John Stultz

=== Highlights === * Mostly caught up from paternity leave * Queued a few timekeeping patches for 3.8 * Discussed need for CLOCK_PERF and possible clock_gettime2() interfaces on lkml * Reviewed patches that allow for vdso pvclock. * Took a quick look at the ashmem/binder fixes for 64bit * Started testing and reviewing Minchan's madvise volatile patch * Sent out Android upstreaming weekly email === Plans === * Continue playing with Minchans madvise volatile patch, trying to see how to best integrate my needs with it. * Try to get a closer review of the ashmem/binder 64bit fixes === Issues === * NA

13 years, 1 month

1
0
0 0

[PATCH V5 0/2] Upstream ST-Ericsson thermal driver

by hongbo.zhang

From: "hongbo.zhang" <hongbo.zhang(a)linaro.com> V4->V5 Changes: In patch "Thermal: Add ST-Ericsson DB8500 thermal driver": - use flush_work instead of flush_work_sync since the later is deprecated now. - parameter trip_points of db8500_thermal_match_cdev is renamed to trip_point; - re-order oprerations in function db8500_thermal_update_config; hongbo.zhang (2): Thermal: Add ST-Ericsson DB8500 thermal driver. Thermal: Add ST-Ericsson DB8500 thermal properties and platform data. .../devicetree/bindings/thermal/db8500-thermal.txt | 44 ++ arch/arm/boot/dts/dbx5x0.dtsi | 14 + arch/arm/boot/dts/snowball.dts | 31 ++ arch/arm/configs/u8500_defconfig | 2 + arch/arm/mach-ux500/board-mop500.c | 64 +++ drivers/thermal/Kconfig | 20 + drivers/thermal/Makefile | 2 + drivers/thermal/db8500_cpufreq_cooling.c | 108 +++++ drivers/thermal/db8500_thermal.c | 531 +++++++++++++++++++++ include/linux/platform_data/db8500_thermal.h | 38 ++ 10 files changed, 854 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/db8500-thermal.txt create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c create mode 100644 drivers/thermal/db8500_thermal.c create mode 100644 include/linux/platform_data/db8500_thermal.h -- 1.7.11.3

13 years, 1 month

5
12
0 0

[PATCH 0/7] KDB: Kiosk (reduced capabilities) mode

by Anton Vorontsov

Hello Jason, Just as promised, I'm resending the series after the merge window. This patchset implements "kiosk" mode for KDB debugger. The mode reduces kdb features, so that it is no longer possible to leak sensitive data via the debugger, and not possible to change program flow in a predefined manner by an ordinary user. Root can control the capability. There are a few patches, some are just cleanups, some are churn-ish cleanups, but inevitable. And the rest implements the mode -- after all the preparations, everything is pretty straightforward. Thanks! Anton. -- include/linux/kdb.h | 20 ++-- kernel/debug/kdb/kdb_bp.c | 24 ++--- kernel/debug/kdb/kdb_main.c | 189 ++++++++++++++++++---------------- kernel/debug/kdb/kdb_private.h | 3 +- kernel/trace/trace_kdb.c | 4 +- 5 files changed, 125 insertions(+), 115 deletions(-)

13 years, 1 month

2
8
0 0

[PATCH v10 0/4] ARM: KDB FIQ debugger

by Anton Vorontsov

Hello Russell, The KDB/NMI core support has been merged into v3.7-rc1, so the only ARM bits are pending now. I believe I addressed all your previous comments, but surely there might be something else to improve, thus would be great if you could take a look at this. The patches were rebased onto v3.7-rc1, and this is the only change in v10. Old changelogs and rationale for these patches can be found here: v1-v5, rationale: http://lkml.org/lkml/2012/9/10/2 v6: http://lkml.org/lkml/2012/9/10/2 v7: http://lkml.org/lkml/2012/9/13/367 v8: http://lkml.org/lkml/2012/9/19/525 v9: http://lkml.org/lkml/2012/9/24/538 Thanks! Anton. -- arch/arm/Kconfig | 19 ++++ arch/arm/common/vic.c | 28 +++++ arch/arm/include/asm/hardware/vic.h | 2 + arch/arm/include/asm/kgdb.h | 8 ++ arch/arm/kernel/Makefile | 1 + arch/arm/kernel/entry-armv.S | 167 +--------------------------- arch/arm/kernel/entry-header.S | 170 +++++++++++++++++++++++++++++ arch/arm/kernel/kgdb_fiq.c | 124 +++++++++++++++++++++ arch/arm/kernel/kgdb_fiq_entry.S | 87 +++++++++++++++ arch/arm/mach-versatile/Makefile | 1 + arch/arm/mach-versatile/kgdb_fiq.c | 31 ++++++ 11 files changed, 472 insertions(+), 166 deletions(-)

13 years, 1 month

2
5
0 0

[ACTIVITY] (Anton Vorontsov) 2012-10-29 - 2012-11-09

by Anton Vorontsov

== Highlights == * Prepared a new, reworked vmpressure API, addressed Minchan comments. Apart of some minor API controversy (syscall vs. vmeventfd/sysfs, etc) the main concern is cgroups integration. So I started working in this direction -- it is definitely doable, but it won't be trivial, though; * Rebased Linaro android tree on v3.7-rc3 (personally, I only tested it on my qemu Versatile "machine", but it seems to work). Along the way, also synced fiq debugger, lowmemorykiller and binder drivers with the latest android-common tree; * Still no reply on KDB/FIQ and KDB/Kiosk patches.

13 years, 1 month

1
0
0 0

[ACTIVITY] (Dong Aisheng) 2012-11-05 - 2012-11-12

by Dong Aisheng

=== Highlights === * KVM/ARM VGIC state saving and restoring implementation. 1) Completed reading common gic code in kernel 2) Completed reading vgic code with refer to ARM GIC v2.0 spec Understand the whole things well in the code including the IRQ injection process and how virtual distributor are implemented and cowork with vitrual interface controller to handle interrupt between host kernel mode and guest mode. 3) Started coding by refer to the common gic state support code, suppose the patch can be sent out within this week if everything goes well. Planned to refer to the common gic suspend/resume state support code like gic_dist_save and gic_dist_restore or other exist interrupt controller kvm state save&restore code of other architecture in kvm framework. * Reviewed the patch series [PATCH v4 00/13] KVM/ARM vGIC support from Christoffer Gave a few comment on some minor issues. * Reviewed a few imx pinctrl patches * Took a sick leave on 11/05 and 11/06

13 years, 1 month

1
0
0 0

[ACTIVITY] (Linus Walleij) 2012-10-23 - 2012-11-10

by Linus Walleij

== Linus Walleij linusw == Sorry for delayed activity report, and Linaro Connect was inbetween so now it's about time to report on what's been going on. === Highlights === * SPARSE_IRQ patch set for Ux500 including the removal of the entire arch/arm/plat-nomadik directory has been merged to ARM SoC. The same patches have been applied to our internal development kernel, so it's not coming back. * Intense activity on pinctrl and gpio trees, sending pull requests for fixes to Torvalds for all random stuff. * Merged the U300 patches cleaning up some pinctrl business to the pinctrl tree. * Intensely debated default-hogging of pinctrl handles. See blueprint just created for details: https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-notifyhog * At Connect Kevin Hilman from TI kindly took time to explain to me and Ulf how runtime PM is to be done right. So what needs to be done is major and will require commitment from Linaro member companies, and I've filed a blueprint for it. https://blueprints.launchpad.net/linux-linaro/+spec/runtime-pm Amit K is informed. * Merged a patch from Shiraz Hashin basically intended to implement this blueprint: https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-gpiorange-makeo… Unfortunately there was some fallout and I set some priority for this over all other work since the tree could not be left in bad shape and I neither wanted to revert the patch. Still hashing things out... * Debated gpio_get(), see the thread beginning with this post: http://marc.info/?l=linux-kernel&m=135167415211671&w=2 Basically the proper solution to this was another blueprint in the making IMHO, so I just had to write it down: https://blueprints.launchpad.net/linux-linaro/+spec/gpio-handles * Russell merged a few SMP_TWD patches I sent making the driver reentrant as cores come and go. This is required for big.LITTLE MP scheduling I think. This is the interesting commit: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7563/1 * Pushed some Integrator-patches moving the irqchip driver to drivers/irqchip and some more. Mainly therapeutic work. * Even sent a clksrc patch for ARM64... * Got IMPD1 and Versatile AB boards from Marc Zyngier @ARM. I owe this guy a favor... now all happy hacking! === Plans === * Attack the remaining headers in arch/arm/mach-ux500 so we can move forward with multiplatform for v3.9 or so. (Make no promises, make no commitments...) * Test the PL08x patches on the Ericsson Research PB11MPCore and submit platform data for using pl08x DMA on that platform. * Look into other Ux500 stuff in need of mainlining... using an internal tracking sheet for this. * Look into regmap. Try something out, get to know it. === Issues === * Classified activity has taken some time and will be reported in 1:1. Thanks, Linus Walleij

13 years, 1 month

2
4
0 0

[PATCH 0/5] Fix thermal bugs and Upstream ST-Ericsson thermal driver

by hongbo.zhang

From: "hongbo.zhang" <hongbo.zhang(a)linaro.com> Hi all, This patch set is to upstream ST-Ericsson thermal driver and fix some bugs of thermal layer at the same time. All of these patches are based on v3.7-rc1. [PATCH 1/5] Thermal: do bind operation after thermal zone or cooling device register returns. In the previous bind function, cdev->get_max_state(cdev, &max_state) is called before the registration function finishes, but at this moment, the parameter cdev at thermal driver layer isn't ready--it will get ready only after its registration, so the the get_max_state callback cannot tell the max_state according to the cdev input. This problem can be fixed by separating the bind operation out of registration and doing it when registration completely finished. There is no such problem with the current exynos thermal driver because it regsters cooling device before thermal zone device. As a generic thermal layer any sequence should be supported, thermal zone first or cooling device first, this will be also helpful to add/remove cooling device dynamically. [PATCH 2/5] Thermal: add indent for code alignment. [PATCH 3/5] Thermal: fix empty list checking method. [PATCH 4/5] Thermal: make sure cpufreq cooling register after cpufreq driver Bug fix for generic cpufreq cooling layer as described in the commit logs. [PATCH 5/5] Thermal: Add ST-Ericsson db8500 thermal dirver. This patch is to add ST-Ericsson into the latest kervel version. hongbo.zhang (5): Thermal: do bind operation after thermal zone or cooling device register returns. Thermal: add indent for code alignment. Thermal: fix empty list checking method. Thermal: make sure cpufreq cooling register after cpufreq driver Thermal: Add ST-Ericsson db8500 thermal dirver. arch/arm/boot/dts/dbx5x0.dtsi | 11 + arch/arm/configs/u8500_defconfig | 4 + arch/arm/mach-ux500/board-mop500.c | 73 ++++ drivers/thermal/Kconfig | 20 ++ drivers/thermal/Makefile | 2 + drivers/thermal/cpu_cooling.c | 19 +- drivers/thermal/db8500_cpufreq_cooling.c | 118 +++++++ drivers/thermal/db8500_thermal.c | 507 +++++++++++++++++++++++++++ drivers/thermal/thermal_sys.c | 86 +++-- include/linux/platform_data/db8500_thermal.h | 39 +++ 10 files changed, 847 insertions(+), 32 deletions(-) create mode 100644 drivers/thermal/db8500_cpufreq_cooling.c create mode 100644 drivers/thermal/db8500_thermal.c create mode 100644 include/linux/platform_data/db8500_thermal.h -- 1.7.11.3

13 years, 1 month

9
76
0 0

Placement of reset code

by Linus Walleij

I remember someone pointing out in the last Linaro Connect saying that we were supposed to push reset frameworks to drivers/power, is that correct? Anyone has a pointer to the relevant discussion? Yours, Linus Walleij

13 years, 1 month

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel