fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
hpt has joined #systemtap
slowfranklin has joined #systemtap
mjw has joined #systemtap
hpt has quit [Ping timeout: 246 seconds]
orivej_ has quit [Ping timeout: 246 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 255 seconds]
wcohen has quit [Remote host closed the connection]
orivej has joined #systemtap
wcohen has joined #systemtap
tromey has joined #systemtap
orivej has quit [Ping timeout: 250 seconds]
khaled has joined #systemtap
sscox has quit [Ping timeout: 250 seconds]
orivej has joined #systemtap
eck has quit [Ping timeout: 250 seconds]
mjw has quit [Quit: Leaving]
eck has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
gromero has joined #systemtap
orivej has quit [Ping timeout: 250 seconds]
wcohen has quit [Ping timeout: 246 seconds]
slowfranklin has quit [Quit: slowfranklin]
wcohen has joined #systemtap
slowfranklin has joined #systemtap
gila has quit [Read error: Connection reset by peer]
slowfranklin has quit [Quit: slowfranklin]
slowfranklin has joined #systemtap
khaled has quit [Quit: Konversation terminated!]
tromey has quit [Quit: ERC (IRC client for Emacs 26.1)]
sscox has joined #systemtap
slowfranklin has quit [Quit: slowfranklin]
<agentzh>
fche: i wonder if it makes sense to use vmalloc to allocate those global stat and map data structures.
<agentzh>
right now the .ko module may fail to load due to fragmentation in the physcal memory space.
<agentzh>
this is especially common in small boxes with little RAM.
<agentzh>
seems like the kernel module loader requires contiguous physical memory blocks for the module being loaded.
<fche>
we've gone through a couple of iterations of allocators
orivej has joined #systemtap
wcohen has quit [Ping timeout: 268 seconds]
<fche>
ISTR vmalloc had some downsides we couldn't accept