What is controlling SQL Server's page file usage? SQL Server or Windows?
Firstly, the most important thing you really need to know is that it is critical to configure memory usage by SQL Server and other applications on the system to ensure that it never starts paging to disk.  RAM access is measured in nanoseconds, and disk access is measured in milliseconds, so whatever gets paged out is going to take hundreds, if not thousands, of times longer to access.  It will also create a massive load of I/O on the system to do the swapping, contending for memory, CPU, and disk access.  So even if you have SSDs, it is still going to hurt if it starts swapping to disk.

When the max memory setting is changed, SQL Server discards everything in the buffer and starts over.  So if it was swapping the buffer to disk, yes, this may have caused the disk swapping to stop and performance somewhat restored.  However, if it was swapping to disk with a 40 GB setting, it will be more likely to swap in the future now that it's going to use even more memory.

However, the change you made could have just been a coincidence--do you know for sure that there were no long-running queries blocking those jobs?  There are dozens of possible causes, and unless you have data from monitoring mechanisms, there's no way to be sure at this point.

Memory management to avoid swapping to disk is one of the dangers of running multiple instances of SQL Server on one system.  If you have 128 GB of RAM, for example, the max memory setting of all instances should only total around 110 GB or so, perhaps a few GB more after monitoring available memory for a while

If SQL Server cannot lock pages in memory, then it has no control over what memory will be swapped to disk.  A process has an address space of virtual memory, and when the process reads the memory, the OS will retrieve it from the physical location (memory, or disk).  The OS keeps track of when memory was last accessed and it tries to page out the memory that is least active to reduce the impact. 

The process does not know about the physical location of each offset of its virtual memory--this could create quite a lot of pointless overhead in tracking it.  SQL Server does, however, have a way of knowing how much of its memory is swapped to disk, as it will log a message as seen in How to reduce paging of buffer pool memory in SQL Server when it reaches a certain threshold. 

Highly recommended reading: RAM, virtual memory, pagefile, and memory management in Windows, particularly to understand that monitoring Memory, Pages/Sec is not a valid measure of memory being swapped to disk.  Many other articles on the Internet incorrectly advise this counter to be used.


  Memory, Pages/Sec: This counter is one of the most misunderstood measures.
  
  A high value for this counter does not necessarily imply that your performance bottleneck stems from a shortage of RAM. The operating system uses the paging system for purposes other than swapping pages because of memory over-commitment.


You can easily verify this by simply having an application write a large amount of data to disk, and you'll see high numbers for Memory, Pages/Sec.  This is because the data that's being written to disk first has to be in memory, and then it is "paged" to disk.  The terminology around "paging" is misunderstood by many system administrators and it is often defined as "swapping process working set to disk," but "paging" is a much broader term than covers every read and write to disk.