Everything here is counted in bits, not bytes. The GCM specification is at least consistent about using bits. Try not thinking about bytes, as these would only increase confusion.
$\lceil\text{len}(IV)/128\rceil$ is: "length of IV, divided by 128, rounded up". So this is the length of IV, counted in number of 128-bit blocks. By multiplying it by 128, you get the length of the smallest sequence of bits that is obtained by appending extra bits to the IV until you get a length with a multiple of 128.
Thus, the expression for $s$:
$$ s = 128 \lceil\text{len}(IV)/128\rceil - \text{len}(IV) $$
really is: the number of bits you must add to the IV in order to get a length which is a multiple of 128.
The underlying idea here is that GHASH can process only data by blocks of 128 bits, so some extra bits must be appended to the IV. Moreover, the original IV length (before padding) must be encoded there, to avoid some attacks (and/or improve security proofs). Thus, the scheme is: append some bits of value zero, then the encoding of the length of the IV over 64 bits. The number of bits of value zero must be between 64 and 191, and also such that the total length (with padding) is a multiple of 128. If you call the number of extra bits of value zero "$s+64$", then $s$ is the value computed by the formula above.
For instance, if your IV has length $209$ bits, then you get $s = 47$ (you need $47$ extra bits to reach the next multiple of $128$, which, in this case, is $256$). Thus, the padding will add $s+64 = 111$ bits of value zero, then the encoding of the original IV length ($209$ bits) over $64$ bits. The number of extra bits will then be $s+64+64 = 175$, for a grand total after padding of $209 + 175 = 384$ bits, which is indeed a multiple of $128$ (hurray!).