does google highway takes more memory than orc?

[gemini133]

sorry, didn't conduct any benchmark/test for this.
got database and libvips oom killed a few times with newly installed vips with highway.

libvips worker invoked oom-killer: gfp_mask=0x100dca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0, oom_score_adj=0
CPU: 2 PID: 2840064 Comm: libvips worker Not tainted 5.10.0-25-amd64 #1 Debian 5.10.191-1
Hardware name: xxx, BIOS 449e491 04/01/2014
Call Trace:
 dump_stack+0x6b/0x83
 dump_header+0x4a/0x1f4
 oom_kill_process.cold+0xb/0x10
 out_of_memory+0x1bd/0x4e0
 __alloc_pages_slowpath.constprop.0+0xbcc/0xc90
 __alloc_pages_nodemask+0x2de/0x310
 alloc_pages_vma+0x80/0x270
 wp_page_copy+0x3b7/0x7b0
 handle_mm_fault+0x1220/0x1c00
 do_user_addr_fault+0x1b8/0x400
 exc_page_fault+0x78/0x160
 ? asm_exc_page_fault+0x8/0x30
 asm_exc_page_fault+0x1e/0x30
RIP: 0033:0x7f4213d4a2f1
Code: 0f 6f c3 66 0f df c2 66 0f eb c1 66 0f 62 e8 66 0f db f3 66 0f 73 df 06 66 0f df df 66 0f eb de 66 44 0f 62 cb 66 44 0f 6c cd <f3> 44 0f 7f 4c 81 10 48 8b 87 10 01 00 00 48 8b b7 68 01 00 00 48
RSP: 002b:00007f420cbefaa0 EFLAGS: 00010287
RAX: 0000000000873bf6 RBX: 00007f420cbefb80 RCX: 00007f419003c010
RDX: 00007f420cbeff20 RSI: 0000000000bfc12d RDI: 00007f420cbefb80
RBP: 0000000000000dcb R08: 0000000000873bfc R09: 0000000000000000
R10: 0000000000873bfd R11: 0000000000873bfb R12: 00007f4213d6f480
R13: 00007f420cbefb80 R14: 0000000000873bf9 R15: 00007f420cbefb00
Mem-Info:
active_anon:13701 inactive_anon:3719464 isolated_anon:0
 active_file:791 inactive_file:865 isolated_file:0
 unevictable:0 dirty:0 writeback:0
 slab_reclaimable:17670 slab_unreclaimable:26562
 mapped:7083 shmem:14382 pagetables:10974 bounce:0
 free:62171 free_pcp:667 free_cma:0
Node 0 active_anon:54804kB inactive_anon:14877856kB active_file:3164kB inactive_file:3460kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:28332kB dirty:0kB writeback:0kB shmem:57528kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 30720kB writeback_tmp:0kB kernel_stack:7136kB all_unreclaimable? no
Node 0 DMA free:13860kB min:68kB low:84kB high:100kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
lowmem_reserve[]: 0 2946 15423 15423 15423
Node 0 DMA32 free:64144kB min:14944kB low:18168kB high:21392kB reserved_highatomic:0KB active_anon:140kB inactive_anon:2925492kB active_file:492kB inactive_file:464kB unevictable:0kB writepending:0kB present:3111608kB managed:3046072kB mlocked:0kB pagetables:908kB bounce:0kB free_pcp:756kB local_pcp:508kB free_cma:0kB
lowmem_reserve[]: 0 0 12477 12477 12477
Node 0 Normal free:170680kB min:173400kB low:187052kB high:200704kB reserved_highatomic:2048KB active_anon:54664kB inactive_anon:11950408kB active_file:4252kB inactive_file:5188kB unevictable:0kB writepending:0kB present:13107200kB managed:12784220kB mlocked:0kB pagetables:42988kB bounce:0kB free_pcp:1912kB local_pcp:400kB free_cma:0kB
lowmem_reserve[]: 0 0 0 0 0
Node 0 DMA: 1*4kB (U) 0*8kB 0*16kB 1*32kB (U) 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 2*2048kB (UM) 2*4096kB (M) = 13860kB
Node 0 DMA32: 227*4kB (UME) 383*8kB (UM) 404*16kB (UM) 508*32kB (UM) 317*64kB (UM) 120*128kB (UM) 10*256kB (UM) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 64900kB
Node 0 Normal: 735*4kB (UMH) 98*8kB (UMH) 9001*16kB (UMEH) 707*32kB (UMEH) 5*64kB (H) 3*128kB (H) 2*256kB (H) 1*512kB (H) 0*1024kB 0*2048kB 0*4096kB = 172092kB
Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
Node 0 hugepages_total=128 hugepages_free=127 hugepages_surp=0 hugepages_size=2048kB
15901 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
4058700 pages RAM
0 pages HighMem/MovableOnly
97150 pages reserved

[jcupitt]

Hi @gemini133,

Memuse should be about the same.

Do you have a log of the images processed before the OOM? Perhaps there was a strange one there?

[kleisauke]

Memory use should indeed be the same or even better because it no longer needs to compile small Orc programs at runtime.

Debian 5.10.191-1

It looks like you are running on Debian 11 (bullseye), which requires you to build Highway from source as it's missing from the package manager. Only Debian 13 (trixie) provides Highway >= 1.0.5 at the time of writing, see:

You can check the presence of Highway with:

$ vips --vips-config | grep SIMD
SIMD support with highway: true
$ vips --targets
builtin targets:   AVX3_SPR AVX3_ZEN4 AVX3 AVX2 SSE4 SSE2
supported targets: AVX3_ZEN4 AVX3_DL AVX3 AVX2 SSE4 SSSE3 SSE2

[gemini133]

thanks for your replies. highway is compiled from source 1.1.0
it happended in the production server at the time of the most actived users online. I rush and switch back to orc vips.
I'll reinstall vips with highway and report back.

[kstanikviacbs]

@gemini133 @kleisauke Apologies for chiming in a little bit into discussion, but as this topic is also currently in my interest I'm wondering what is your suggestion for that case - I mean - is switching to trixie given it's still not stable worth it to start utilizing highway? (I want to avoid building from sources or switching distro at this point). Thanks in advance for recommendation!

[gemini133]

vips --targets
builtin targets: AVX3_SPR AVX3_ZEN4 AVX3 AVX2 SSE4 SSE2
supported targets: AVX3 AVX2 SSE4 SSSE3 SSE2

vips --vips-config
SIMD support with highway: true
accelerate loops with ORC: false

vips --version
vips-8.15.1

I reinstall back. let's how it goes with my production server... hopefully wont'get alert midnight again...

[gemini133]

so far so good!

[gemini133]

actually, I'm experiencing segfault with libvips from time to time. But once retried, it goes away... didn't dig further.
today, I recompile libvips without highway but with orc.
just a hunch that this could be caused by highway but I don't have any proof.
reopen this thread and will update after 30 days.

[jcupitt]

Thanks @gemini133.

You could also try setting the env var VIPS_NOVECTOR to disable all vector paths and switch to the vanilla C fallback, it might help isolate the issue.